From conal at conal.net Mon Feb 1 01:16:24 2016 From: conal at conal.net (Conal Elliott) Date: Sun, 31 Jan 2016 17:16:24 -0800 Subject: Specializing expressions beyond names? In-Reply-To: References: Message-ID: A related question: if there are a great many rules of the form "reify (foo ...) = ...", where 'reify' is always present (and the outermost application head) but for many different argument expressions, will rule matching be linear (expensive) in the number of such rules? -- Conal On Sun, Jan 31, 2016 at 1:58 PM, Conal Elliott wrote: > It seems to be the case that SPECIALIZE pragmas are syntactically > restricted to type specializations of a *name* (identifier) rather than a > general expression. Is my understanding correct here? If so, is there any > reason for this restriction? > > I ask because I?m reifying Core code (into code that constructs a > corresponding run-time representation for further processing), and I?m > looking for a clean way to integrate that process with GHC, to support > separate compilation and to avoid interfering with GHC?s regular flow. It > occurred to me that I could enable separate compilation via a pragma of the > form ?{-# SPECIALIZE reify foo ? E t #-}? for some t, where E t is a > reified form of values of type t. Type checking would infer the > specialized type of foo, and the usual specialization phase would do its > usual thing on that specialization, leaving ?reify foo = reify > specialized_foo?, and then the reification compiler plugin would > transform the right-hand side, pushing the reify inward. Some reify calls > may remain (e.g., due to polymorphism), triggering future rule > applications. As much as possible of the fully-reified version would be > factored out of the generated rule?s RHS for cheap reuse. > > > Thanks, - Conal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.stolarek at p.lodz.pl Mon Feb 1 07:21:20 2016 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Mon, 1 Feb 2016 08:21:20 +0100 Subject: Best practices for merging? In-Reply-To: <56AE4E22.8070502@apeiron.net> References: <56AE4E22.8070502@apeiron.net> Message-ID: <201602010821.21068.jan.stolarek@p.lodz.pl> > rebase onto master, and then merge with an empty merge commit, i..e, *not* fast-forward. I was under the impression - perhaps incorrect - that it is our policy to avoid merge commits, ie. do only fast-forward merges. And when I look at git history I see very few merge commits. > This lets me look at the repo history and easily see where a feature branch landed and get a > good idea of what changes it contains. I always considered merge commits to be obscuring history, both making it hard to read and understand. Two commits instead of one does not sound desirable. And you can always see what changes were introduced by a patch, with or without merge commit. But perhaps I am missing something here. Janek > This lets me look at the repo history > and easily see where a feature branch landed and get a good idea of what > changes it contains. I have used this approach in the past with GHC, > e.g., SIMD support and typed TH. > > For smaller sets of changes, I might skip the merge commit, but I still > break up my changes into discreet bits, which helps anyone reading the > change set to see what's going on. > > It seems the current policy is to submit changes via Phab and then, > after approval, squash everything into a single patch and apply it with > arc. At least that is my reading of > https://ghc.haskell.org/trac/ghc/wiki/Phabricator/Extras#Landingreviews. > Is that what I should be doing? > > For feature branches, is that also what is advised? > > Thanks, > Geoff > > _______________________________________________ > 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 simonpj at microsoft.com Mon Feb 1 08:57:55 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 1 Feb 2016 08:57:55 +0000 Subject: Nailing down what we expect IO to do and not do - and why In-Reply-To: References: Message-ID: <34f6cb27a0b14c79bd3d2014d5d9f368@DB4PR30MB030.064d.mgd.msft.net> If you are thinking about the compiler internals, then knowing about State# etc is necessary. ?Digging it up in the compiler is hard? Indeed, and you should not have to do that. If you are think about programmers, and how they reason about their programs, then my working hypothesis is that all that stuff should be irrelevant, and indeed confusing. State# etc is just an implementation technique. Just use the semantics in ?Tackling the awkward squad?. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Christopher Allen Sent: 31 January 2016 01:57 To: ghc-devs at haskell.org Subject: Nailing down what we expect IO to do and not do - and why I'm writing a book, I'd like to get this nailed down and to get it right. If anyone on here that's familiar with the various ways in which IO/State#/realWorld# work in GHC and you have time to reply, anything at all would be welcome. Any pointers, links, references, details, anecdotes, or faint memories of GHC bugs will be greatly appreciated! Getting this written up (possibly for addition to Michael Snoyman's wiki article?) would make me, and I imagine others, a lot happier with trying to understand how the different bits and bobs fit together. I will be dumping my notes as I don't want to get linked to stuff that can be googled because I've already lost 10-15 hours to just that in the past 3-4 days. Digging it up in the compiler is hard because compiler behavior that influences how IO actions are treated don't necessarily have "IO" or "realWorld" mentioned in the relevant parts of the compiler, optimizations, etc. What I'm hoping for is answers on what specifically preserves the listed properties we want from IO in the compiler, prims, or structure of how we write IO actions. What we expect IO to do: - Disable sharing of results, even when it's not a lambda and is evaluated multiple times by the same name. ie, getCurrentTime :: IO UTCTime should get evaluated more than once. - Not reorder sequential IO actions, such as in a do-block. Called "linearity" below - Not duplicate the effects of IO actions. Effects shouldn't be spuriously duplicated during optimization passes. - Effects should not be discarded separately of the value returned by an IO action, merged, or elided. # Sharing A friend suggested that perhaps one-shot semantics via the state hack for State# in the IO type is responsible for disabling sharing, I don't believe so, but here are my notes. >-fno-state-hack >Turn off the "state hack" whereby any lambda with a State# token as argument is considered to be single-entry, hence it is considered OK to inline things inside it. This can improve performance of IO and ST monad code, but it runs the risk of reducing sharing. >A one shot lambda >State hack, makes the lambda over State# assume it's one-shot universally by default. >one-shot/state hack is an anti-inlining heuristic, suggesting that inlining is costly. Also I found this on Trac, does anyone know the answer to this? Is the summary above accurate? >Can the IO state hack be avoided if oneShot is used in the right places in library code, e.g. in IO?s definition of >>=? This seems related how the state token works, for differentiating which IO action is which and how many times an IO action should run, when it should run, etc. From the prims: >data State# s >State# is the primitive, unlifted type of states. It has one type parameter, thus State# RealWorld, or State# s, where s is a type variable. The only purpose of the type parameter is to keep different state threads separate. It is represented by nothing at all. >data RealWorld >RealWorld is deeply magical. It is primitive, but it is not unlifted (hence ptrArg). We never manipulate values of type RealWorld; it's only used in the type system, to parameterise State#. # Linearity Is this from the nesting of lambdas? It doesn't seem like that's enough based on the various examples using State/State# in GHC Trac bug tickets. The RealWorld token seems to be what's driving this but precisely how that works hasn't been easy to find. # Discarding, not inlining effects I believe these are addressed by has_side_effects in the prim ops. I could very well be wrong. can_fail has_side_effects Discard NO NO Float in YES YES Float out NO NO Duplicate YES NO * Duplication. You cannot duplicate a has_side_effect primop. You might wonder how this can occur given the state token threading, but just look at Control.Monad.ST.Lazy.Imp.strictToLazy! We get something like this p = case readMutVar# s v of (# s', r #) -> (S# s', r) s' = case p of (s', r) -> s' r = case p of (s', r) -> r I believe duplication addresses inlining IO actions more generally but I could be wrong. Here's a note I found regarding elision/merging: * Use the compiler flag @-fno-cse@ to prevent common sub-expression elimination being performed on the module, which might combine two side effects that were meant to be separate. A good example is using multiple global variables (like @test@ in the example below). Any help or pointers for nailing down and documenting this would be greatly appreciated. Also if there's a more detailed explanation of what behavior is expected out of each unsafe function, that would help as well. There are bits and pieces I've been able to aggregate from the GHC trac tickets. References used (not exhaustive): - Referential Transparency; Haskell Wiki https://wiki.haskell.org/Referential_transparency - IO Inside; Haskell Wiki https://wiki.haskell.org/IO_inside - Unraveling the mystery of the IO Monad; Edward Z. Yang http://blog.ezyang.com/2011/05/unraveling-the-mystery-of-the-io-monad/ - Evaluation order and state tokens; Michael Snoyman https://wiki.haskell.org/Evaluation_order_and_state_tokens - Haskell GHC Illustrated; Takenobu Tani - Tackling the Awkward Squad; Simon Peyton Jones http://research.microsoft.com/en-us/um/people/simonpj/papers/marktoberdorf/mark.pdf - Note [IO hack in the demand analyser]; GHC source code - Monadic I/O in Haskell 1.3; Andrew D. Gordon and Kevin Hammond - Haskell Report 1.2 http://haskell.cs.yale.edu/wp-content/uploads/2011/01/haskell-report-1.2.pdf Thank you for your time, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Mon Feb 1 10:41:22 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Mon, 1 Feb 2016 04:41:22 -0600 Subject: Nailing down what we expect IO to do and not do - and why In-Reply-To: <34f6cb27a0b14c79bd3d2014d5d9f368@DB4PR30MB030.064d.mgd.msft.net> References: <34f6cb27a0b14c79bd3d2014d5d9f368@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Right, I'm seeking to understand the internals more generally, but specifically I'd like to know the answers to my questions in my original email. I'd really appreciate some pointers and information on this. On Mon, Feb 1, 2016 at 2:57 AM, Simon Peyton Jones wrote: > If you are thinking about the compiler internals, then knowing about > State# etc is necessary. ?Digging it up in the compiler is hard? > Indeed, and you should not have to do that. > > > > If you are think about *programmers*, and how they *reason about their > programs*, then my working hypothesis is that all that stuff should be > irrelevant, and indeed confusing. State# etc is just an implementation > technique. Just use the semantics in ?Tackling the awkward squad?. > > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Christopher > Allen > *Sent:* 31 January 2016 01:57 > *To:* ghc-devs at haskell.org > *Subject:* Nailing down what we expect IO to do and not do - and why > > > > I'm writing a book, I'd like to get this nailed down and to get it right. > If anyone on here that's familiar with the various ways in which > IO/State#/realWorld# work in GHC and you have time to reply, anything at > all would be welcome. Any pointers, links, references, details, anecdotes, > or faint memories of GHC bugs will be greatly appreciated! Getting this > written up (possibly for addition to Michael Snoyman's wiki article?) would > make me, and I imagine others, a lot happier with trying to understand how > the different bits and bobs fit together. > > > > I will be dumping my notes as I don't want to get linked to stuff that can > be googled because I've already lost 10-15 hours to just that in the past > 3-4 days. Digging it up in the compiler is hard because compiler behavior > that influences how IO actions are treated don't necessarily have "IO" or > "realWorld" mentioned in the relevant parts of the compiler, optimizations, > etc. > > > > What I'm hoping for is answers on what specifically preserves the listed > properties we want from IO in the compiler, prims, or structure of how we > write IO actions. > > > > > > What we expect IO to do: > > > > - Disable sharing of results, even when it's not a lambda and is evaluated > multiple times by the same name. ie, getCurrentTime :: IO UTCTime should > get evaluated more than once. > > > > - Not reorder sequential IO actions, such as in a do-block. Called > "linearity" below > > > > - Not duplicate the effects of IO actions. Effects shouldn't be spuriously > duplicated during optimization passes. > > > > - Effects should not be discarded separately of the value returned by an > IO action, merged, or elided. > > > > > > # Sharing > > > > A friend suggested that perhaps one-shot semantics via the state hack for > State# in the IO type is responsible for disabling sharing, I don't believe > so, but here are my notes. > > > > >-fno-state-hack > > >Turn off the "state hack" whereby any lambda with a State# token as > argument is considered to be single-entry, hence it is considered OK to > inline things inside it. This can improve performance of IO and ST monad > code, but it runs the risk of reducing sharing. > > > > >A one shot lambda > > >State hack, makes the lambda over State# assume it's one-shot universally > by default. > > >one-shot/state hack is an anti-inlining heuristic, suggesting that > inlining is costly. > > > > Also I found this on Trac, does anyone know the answer to this? Is the > summary above accurate? > > > > >Can the IO state hack be avoided if oneShot is used in the right places > in library code, e.g. in IO?s definition of >>=? > > > > This seems related how the state token works, for differentiating which IO > action is which and how many times an IO action should run, when it should > run, etc. > > > > From the prims: > > > > >data State# s > > > > >State# is the primitive, unlifted type of states. It has one type > parameter, thus State# RealWorld, or State# s, where s is a type variable. > The only purpose of the type parameter is to keep different state threads > separate. It is represented by nothing at all. > > > > >data RealWorld > > > > >RealWorld is deeply magical. It is primitive, but it is not unlifted > (hence ptrArg). We never manipulate values of type RealWorld; it's only > used in the type system, to parameterise State#. > > > > > > # Linearity > > > > Is this from the nesting of lambdas? It doesn't seem like that's enough > based on the various examples using State/State# in GHC Trac bug tickets. > The RealWorld token seems to be what's driving this but precisely how that > works hasn't been easy to find. > > > > > > # Discarding, not inlining effects > > > > I believe these are addressed by has_side_effects in the prim ops. I could > very well be wrong. > > > > can_fail has_side_effects > > Discard NO NO > > Float in YES YES > > Float out NO NO > > Duplicate YES NO > > > > * Duplication. You cannot duplicate a has_side_effect primop. You > > might wonder how this can occur given the state token threading, but > > just look at Control.Monad.ST.Lazy.Imp.strictToLazy! We get > > something like this > > p = case readMutVar# s v of > > (# s', r #) -> (S# s', r) > > s' = case p of (s', r) -> s' > > r = case p of (s', r) -> r > > > I believe duplication addresses inlining IO actions more generally but I > could be wrong. Here's a note I found regarding elision/merging: > > > > * Use the compiler flag @-fno-cse@ to prevent common sub-expression > > elimination being performed on the module, which might combine > > two side effects that were meant to be separate. A good example > > is using multiple global variables (like @test@ in the example > below). > > > > > > > > Any help or pointers for nailing down and documenting this would be > greatly appreciated. Also if there's a more detailed explanation of what > behavior is expected out of each unsafe function, that would help as well. > There are bits and pieces I've been able to aggregate from the GHC trac > tickets. > > > > > > References used (not exhaustive): > > > > - Referential Transparency; Haskell Wiki > > https://wiki.haskell.org/Referential_transparency > > > > > - IO Inside; Haskell Wiki > > https://wiki.haskell.org/IO_inside > > > > > - Unraveling the mystery of the IO Monad; Edward Z. Yang > > http://blog.ezyang.com/2011/05/unraveling-the-mystery-of-the-io-monad/ > > > > > - Evaluation order and state tokens; Michael Snoyman > > https://wiki.haskell.org/Evaluation_order_and_state_tokens > > > > > - Haskell GHC Illustrated; Takenobu Tani > > > > - Tackling the Awkward Squad; Simon Peyton Jones > > > http://research.microsoft.com/en-us/um/people/simonpj/papers/marktoberdorf/mark.pdf > > > > > - Note [IO hack in the demand analyser]; GHC source code > > > > - Monadic I/O in Haskell 1.3; Andrew D. Gordon and Kevin Hammond > > > > - Haskell Report 1.2 > > > http://haskell.cs.yale.edu/wp-content/uploads/2011/01/haskell-report-1.2.pdf > > > > > > > Thank you for your time, > > Chris > -- Chris Allen Currently working on http://haskellbook.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Feb 1 10:59:19 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 1 Feb 2016 10:59:19 +0000 Subject: Best practices for merging? In-Reply-To: <56AE4E22.8070502@apeiron.net> References: <56AE4E22.8070502@apeiron.net> Message-ID: <32b958f7b3e5470d8b1fbea913d8cde4@DB4PR30MB030.064d.mgd.msft.net> I'm no git expert here, but * Feature branches typically have lots of intermediate fixups. We don?t want that sequence in the main history; it's like watching sausage being made, and many intermediate points may be broken. Better to have one big, coherent commit. * If a feature branch really has several independent pieces, then yes, it'd be better to make several commits. Perhaps Phab doesn't support this well. In that case, would it make sense to make each into a separate Phab ticket? * I have no idea what an "empty merge commit" is, or why it might be better that "a commit". After all, a fast-forward commit is no different to cloning, doing a very quick job on the feature, and committing. What am I missing? Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Geoffrey | Mainland | Sent: 31 January 2016 18:11 | To: ghc-devs at haskell.org Devs | Subject: Best practices for merging? | | I've been away from GHC for a while, and it's not clear to me what the | best practices for merging are now. | | My usual git workflow is to work on a feature branch, get a nice clean | set of patches, each of which implements a discrete bit of | functionality, rebase onto master, and then merge with an empty merge | commit, i..e, *not* fast-forward. This lets me look at the repo history | and easily see where a feature branch landed and get a good idea of what | changes it contains. I have used this approach in the past with GHC, | e.g., SIMD support and typed TH. | | For smaller sets of changes, I might skip the merge commit, but I still | break up my changes into discreet bits, which helps anyone reading the | change set to see what's going on. | | It seems the current policy is to submit changes via Phab and then, | after approval, squash everything into a single patch and apply it with | arc. At least that is my reading of | https://ghc.haskell.org/trac/ghc/wiki/Phabricator/Extras#Landingreviews. | Is that what I should be doing? | | For feature branches, is that also what is advised? | | Thanks, | Geoff | | _______________________________________________ | 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%7c0b2671ff9bed4a35ddd108 | d32a69d7a9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=XIbsIBRwd3bLRha9OjVxw | jdyEas6qnTNnciHvjCyC9E%3d From ben at smart-cactus.org Mon Feb 1 13:13:34 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 01 Feb 2016 14:13:34 +0100 Subject: Best practices for merging? In-Reply-To: <32b958f7b3e5470d8b1fbea913d8cde4@DB4PR30MB030.064d.mgd.msft.net> References: <56AE4E22.8070502@apeiron.net> <32b958f7b3e5470d8b1fbea913d8cde4@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <87d1sgd14x.fsf@smart-cactus.org> Simon Peyton Jones writes: > I'm no git expert here, but > > * Feature branches typically have lots of intermediate fixups. > We don?t want that sequence in the main history; it's like > watching sausage being made, and many intermediate points may > be broken. Better to have one big, coherent commit. > > * If a feature branch really has several independent pieces, then > yes, it'd be better to make several commits. Perhaps Phab doesn't > support this well. In that case, would it make sense to make > each into a separate Phab ticket? > > * I have no idea what an "empty merge commit" is, or why it might > be better that "a commit". > > After all, a fast-forward commit is no different to cloning, doing > a very quick job on the feature, and committing. > If there are multiple commits then a merge commit can serve to logically group them. For instance, in the case of Geoff's recent fix, $ git log --graph --oneline origin/master * e5a0a89 Suppress substitution assertions to fix tests * a883c1b Missing @since annotations in GHC.Generics * f8e2b7e Minor doc fixes to GHC.Generics * 34519f0 When encountering a duplicate symbol, show source of the first symbol * 669cbef Fix Trac issue #11487. |\ | * 6544f8d Properly track live registers when saving the CCCS. | * 90f688e Code formatting cleanup. | * 4d0e4fe Add type signatures. |/ * b61f5f7 Put docs in /usr/share/doc/ghc- Here we see that those three commits were developed on a feature branch, which was then merged into master in 669cbef. For what it's worth I quite like this practice. That being said, in GHC we rarely have changes broken up into multiple commits like this, in part due to Phab's poor support for fine-grained changes. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From jan.stolarek at p.lodz.pl Mon Feb 1 14:44:55 2016 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Mon, 1 Feb 2016 15:44:55 +0100 Subject: Best practices for merging? In-Reply-To: <87d1sgd14x.fsf@smart-cactus.org> References: <56AE4E22.8070502@apeiron.net> <32b958f7b3e5470d8b1fbea913d8cde4@DB4PR30MB030.064d.mgd.msft.net> <87d1sgd14x.fsf@smart-cactus.org> Message-ID: <201602011544.55192.jan.stolarek@p.lodz.pl> > If there are multiple commits then a merge commit can serve to logically > group them. The cost of this is non-linear history. But I am still not sure what the actual benefit is? If the commits come one after another they are still logically grouped, with or without a merge commit. I also wonder what is the preferred way of viewing history for most of the people. I either use `git log` or github, but rarely resort to gitk. Only the latter makes the non-linear commits explicitly visible. The former two just collapse everything into a linear history and is such a setting merge commits are a major clutter. So perhaps that's why I don't like them. Perhaps people who tend to use gitk are more keen on merge commits? Janek > For instance, in the case of Geoff's recent fix, > > $ git log --graph --oneline origin/master > * e5a0a89 Suppress substitution assertions to fix tests > * a883c1b Missing @since annotations in GHC.Generics > * f8e2b7e Minor doc fixes to GHC.Generics > * 34519f0 When encountering a duplicate symbol, show source of the > first symbol * 669cbef Fix Trac issue #11487. > > |\ > | * 6544f8d Properly track live registers when saving the CCCS. > | * 90f688e Code formatting cleanup. > | * 4d0e4fe Add type signatures. > |/ > > * b61f5f7 Put docs in /usr/share/doc/ghc- > > Here we see that those three commits were developed on a feature branch, > which was then merged into master in 669cbef. > > For what it's worth I quite like this practice. That being said, in GHC > we rarely have changes broken up into multiple commits like this, in > part due to Phab's poor support for fine-grained changes. > > Cheers, > > - Ben --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From hesselink at gmail.com Mon Feb 1 14:58:22 2016 From: hesselink at gmail.com (Erik Hesselink) Date: Mon, 1 Feb 2016 15:58:22 +0100 Subject: Best practices for merging? In-Reply-To: <201602011544.55192.jan.stolarek@p.lodz.pl> References: <56AE4E22.8070502@apeiron.net> <32b958f7b3e5470d8b1fbea913d8cde4@DB4PR30MB030.064d.mgd.msft.net> <87d1sgd14x.fsf@smart-cactus.org> <201602011544.55192.jan.stolarek@p.lodz.pl> Message-ID: On 1 February 2016 at 15:44, Jan Stolarek wrote: > I also wonder what is the preferred way of viewing history for most of the people. I either use > `git log` or github, but rarely resort to gitk. Only the latter makes the non-linear commits > explicitly visible. The former two just collapse everything into a linear history and is such a > setting merge commits are a major clutter. So perhaps that's why I don't like them. Perhaps > people who tend to use gitk are more keen on merge commits? Just as a side-note: git log has a --no-merges option to show only non-merge commits. That might make your experience a little better when working on such code bases. Alternatively, you can pass --graph (best combined with something like --oneline) to view a gitk like graph that shows the merges. Erik From mainland at apeiron.net Mon Feb 1 15:25:06 2016 From: mainland at apeiron.net (Geoffrey Mainland) Date: Mon, 1 Feb 2016 10:25:06 -0500 Subject: Best practices for merging? In-Reply-To: <201602011544.55192.jan.stolarek@p.lodz.pl> References: <56AE4E22.8070502@apeiron.net> <32b958f7b3e5470d8b1fbea913d8cde4@DB4PR30MB030.064d.mgd.msft.net> <87d1sgd14x.fsf@smart-cactus.org> <201602011544.55192.jan.stolarek@p.lodz.pl> Message-ID: <56AF78D2.9000307@apeiron.net> On 02/01/2016 09:44 AM, Jan Stolarek wrote: >> If there are multiple commits then a merge commit can serve to logically >> group them. > The cost of this is non-linear history. But I am still not sure what the actual benefit is? If the > commits come one after another they are still logically grouped, with or without a merge commit. In a purely linear history, it is not immediately clear how the commits are grouped---there is just a single stream of commits, so in effect, there is only one "group." > I also wonder what is the preferred way of viewing history for most of the people. I either use > `git log` or github, but rarely resort to gitk. Only the latter makes the non-linear commits > explicitly visible. The former two just collapse everything into a linear history and is such a > setting merge commits are a major clutter. So perhaps that's why I don't like them. Perhaps > people who tend to use gitk are more keen on merge commits? I use gitk extensively, so perhaps that's why I like using empty merge commits to mark groups of patches. This lets me scroll through the repo history and see when major features landed. For my recent fix, I can see why one might prefer a fast-forward merge. But for feature branches that have 10-15 (or more) commits, especially when multiple people have contributed to a feature branch, an empty merge commit marks (and documents) that this group of patches implements a significant feature. If these 10-15 commits were merged fast-forward, then it would not be immediately obvious that they were all part of the same group, nor would it be obvious from scrolling through the history that they were all part of significant feature X landing. If one doesn't use gitk, I can see why empty merge commits would not be so appealing. In the past, the GHC history has been littered with merge commits, some of them non-empty, often because of a git pull without --rebase. So our history is certainly not merge free---even recently. I would agree that those kinds of merges are not desirable, and non-empty merge commits are especially unpleasant. Squashing large change sets into a single patch is also undesirable---it makes figuring out exactly what changed more difficult and makes bisecting less useful. Again, I'm not trying to impose a workflow---I just wasn't sure if there was a new recommended workflow. Cheers, Geoff >> For instance, in the case of Geoff's recent fix, >> >> $ git log --graph --oneline origin/master >> * e5a0a89 Suppress substitution assertions to fix tests >> * a883c1b Missing @since annotations in GHC.Generics >> * f8e2b7e Minor doc fixes to GHC.Generics >> * 34519f0 When encountering a duplicate symbol, show source of the >> first symbol * 669cbef Fix Trac issue #11487. >> >> |\ >> | * 6544f8d Properly track live registers when saving the CCCS. >> | * 90f688e Code formatting cleanup. >> | * 4d0e4fe Add type signatures. >> |/ >> >> * b61f5f7 Put docs in /usr/share/doc/ghc- >> >> Here we see that those three commits were developed on a feature branch, >> which was then merged into master in 669cbef. >> >> For what it's worth I quite like this practice. That being said, in GHC >> we rarely have changes broken up into multiple commits like this, in >> part due to Phab's poor support for fine-grained changes. >> >> Cheers, >> >> - Ben > From ben at smart-cactus.org Mon Feb 1 16:04:02 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 01 Feb 2016 17:04:02 +0100 Subject: Best practices for merging? In-Reply-To: <201602011544.55192.jan.stolarek@p.lodz.pl> References: <56AE4E22.8070502@apeiron.net> <32b958f7b3e5470d8b1fbea913d8cde4@DB4PR30MB030.064d.mgd.msft.net> <87d1sgd14x.fsf@smart-cactus.org> <201602011544.55192.jan.stolarek@p.lodz.pl> Message-ID: <87a8nkct8t.fsf@smart-cactus.org> Jan Stolarek writes: >> If there are multiple commits then a merge commit can serve to logically >> group them. > The cost of this is non-linear history. But I am still not sure what the actual benefit is? If the > commits come one after another they are still logically grouped, with or without a merge commit. > > I also wonder what is the preferred way of viewing history for most of the people. I either use > `git log` or github, but rarely resort to gitk. Only the latter makes the non-linear commits > explicitly visible. The former two just collapse everything into a linear history and is such a > setting merge commits are a major clutter. So perhaps that's why I don't like them. Perhaps > people who tend to use gitk are more keen on merge commits? > Indeed I make quite frequent use of gitk (even git log --graph is pretty usable). Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From eir at cis.upenn.edu Mon Feb 1 17:10:32 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 1 Feb 2016 12:10:32 -0500 Subject: Best practices for merging? In-Reply-To: <87a8nkct8t.fsf@smart-cactus.org> References: <56AE4E22.8070502@apeiron.net> <32b958f7b3e5470d8b1fbea913d8cde4@DB4PR30MB030.064d.mgd.msft.net> <87d1sgd14x.fsf@smart-cactus.org> <201602011544.55192.jan.stolarek@p.lodz.pl> <87a8nkct8t.fsf@smart-cactus.org> Message-ID: <332C9AC4-CAEB-4891-8267-AB790348E46B@cis.upenn.edu> I have this in effect: alias gitlog='git log --graph --full-history --all --color --pretty=format:"%x1b[31m%h%x09%x1b[32m%d%x1b[0m%x20%s"' I didn't come up with the incantation (and I forget the source), but it has obviated entirely my use of gitk. I use this command many times a day. Richard On Feb 1, 2016, at 11:04 AM, Ben Gamari wrote: > Jan Stolarek writes: > >>> If there are multiple commits then a merge commit can serve to logically >>> group them. >> The cost of this is non-linear history. But I am still not sure what the actual benefit is? If the >> commits come one after another they are still logically grouped, with or without a merge commit. >> >> I also wonder what is the preferred way of viewing history for most of the people. I either use >> `git log` or github, but rarely resort to gitk. Only the latter makes the non-linear commits >> explicitly visible. The former two just collapse everything into a linear history and is such a >> setting merge commits are a major clutter. So perhaps that's why I don't like them. Perhaps >> people who tend to use gitk are more keen on merge commits? >> > Indeed I make quite frequent use of gitk (even git log --graph is pretty > usable). > > Cheers, > > - Ben > > _______________________________________________ > 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 Feb 1 17:11:01 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 1 Feb 2016 17:11:01 +0000 Subject: Best practices for merging? In-Reply-To: <56AF78D2.9000307@apeiron.net> References: <56AE4E22.8070502@apeiron.net> <32b958f7b3e5470d8b1fbea913d8cde4@DB4PR30MB030.064d.mgd.msft.net> <87d1sgd14x.fsf@smart-cactus.org> <201602011544.55192.jan.stolarek@p.lodz.pl> <56AF78D2.9000307@apeiron.net> Message-ID: | Squashing large change sets into a single patch is also undesirable--- | it makes figuring out exactly what changed more difficult and makes | bisecting less useful. My personal preference is: * Always squash the "sausage-being-made" commits of a feature branch. The sometimes-torturous history is not of interest to later readers. * If a feature-branch-author is willing to take the time to break the feature into a bunch of related sub-feature, each with its own, documented, self-contained commit -- then excellent! * Avoid non-empty merge commits. * I'm agnostic about the empty-merge-commit thing, but now I can see the logic and am fine with having them. The guiding principle is: keep information that is valuable in later years; discard noise that will simply be distracting in later years. But like Geoff I'm not trying to impose anything, since I regard myself as a git amateur. I'd love someone to write down the result of this conversation in our working conventions. Simon | | Again, I'm not trying to impose a workflow---I just wasn't sure if | there was a new recommended workflow. | | Cheers, | Geoff | | >> For instance, in the case of Geoff's recent fix, | >> | >> $ git log --graph --oneline origin/master | >> * e5a0a89 Suppress substitution assertions to fix tests | >> * a883c1b Missing @since annotations in GHC.Generics | >> * f8e2b7e Minor doc fixes to GHC.Generics | >> * 34519f0 When encountering a duplicate symbol, show source of | the | >> first symbol * 669cbef Fix Trac issue #11487. | >> | >> |\ | >> | * 6544f8d Properly track live registers when saving the CCCS. | >> | * 90f688e Code formatting cleanup. | >> | * 4d0e4fe Add type signatures. | >> |/ | >> | >> * b61f5f7 Put docs in /usr/share/doc/ghc- | >> | >> Here we see that those three commits were developed on a feature | >> branch, which was then merged into master in 669cbef. | >> | >> For what it's worth I quite like this practice. That being said, in | >> GHC we rarely have changes broken up into multiple commits like | this, | >> in part due to Phab's poor support for fine-grained changes. | >> | >> Cheers, | >> | >> - Ben | > | | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha | skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c41dd179c03104456 | 6c7608d32b1be29a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Y%2buUjGT | 9llfuw4mmRZA3TdL%2fmAKhx2pL3954UZN6Y5c%3d From omeragacan at gmail.com Mon Feb 1 22:05:54 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Mon, 1 Feb 2016 17:05:54 -0500 Subject: StgCase - are LiveVars and SRT fields going to be used? Message-ID: Hi all, This is how case expression in STG currently defined: | StgCase (GenStgExpr bndr occ) (GenStgLiveVars occ) (GenStgLiveVars occ) bndr SRT AltType [GenStgAlt bndr occ] The GenStgLiveVars and SRT fields are never used anywhere in the compiler (except the printer). So the question is, I'm assuming those were used at some point, but are they going to be used in the future? Or can I just delete those? As a proof of concept, I just compiled GHC using this: | StgCase (GenStgExpr bndr occ) bndr AltType [GenStgAlt bndr occ] Normally this is not a big deal, but I'm doing lots of STG-to-STG transformations nowadays, and I have to keep those field updated which is annoying as those are never going to be used (I can't even know if I'm doing it right), or leave those `undefined` which is not a good practice. From simonpj at microsoft.com Mon Feb 1 23:04:18 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 1 Feb 2016 23:04:18 +0000 Subject: StgCase - are LiveVars and SRT fields going to be used? In-Reply-To: References: Message-ID: <7edb9d617aa344ce8b6fcf4d3b27849c@DB4PR30MB030.064d.mgd.msft.net> Those fields are dead, now that the Cmm pass deals with it. We left it in while making the transition, but they can go now. Go ahead! (Lots of code should disappear along with them!) Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of ?mer Sinan | Agacan | Sent: 01 February 2016 22:06 | To: ghc-devs | Subject: StgCase - are LiveVars and SRT fields going to be used? | | Hi all, | | This is how case expression in STG currently defined: | | | | StgCase | (GenStgExpr bndr occ) | (GenStgLiveVars occ) | (GenStgLiveVars occ) | bndr | SRT | AltType | [GenStgAlt bndr occ] | | | The GenStgLiveVars and SRT fields are never used anywhere in the compiler | (except the printer). So the question is, I'm assuming those were used at | some | point, but are they going to be used in the future? Or can I just delete | those? | | As a proof of concept, I just compiled GHC using this: | | | | StgCase | (GenStgExpr bndr occ) | bndr | AltType | [GenStgAlt bndr occ] | | | Normally this is not a big deal, but I'm doing lots of STG-to-STG | transformations nowadays, and I have to keep those field updated which is | annoying as those are never going to be used (I can't even know if I'm doing | it | right), or leave those `undefined` which is not a good practice. | _______________________________________________ | 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%7c12ca56c8fc514f477f7f08 | d32b53f4bc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=LPiupNbUJ9OGL9cmbP%2f | PAs2JSdxqlxk%2bGbXuYTHFbzg%3d From omeragacan at gmail.com Tue Feb 2 01:19:07 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Mon, 1 Feb 2016 20:19:07 -0500 Subject: StgCase - are LiveVars and SRT fields going to be used? In-Reply-To: <7edb9d617aa344ce8b6fcf4d3b27849c@DB4PR30MB030.064d.mgd.msft.net> References: <7edb9d617aa344ce8b6fcf4d3b27849c@DB4PR30MB030.064d.mgd.msft.net> Message-ID: https://phabricator.haskell.org/D1880 2016-02-01 18:04 GMT-05:00 Simon Peyton Jones : > Those fields are dead, now that the Cmm pass deals with it. We left it in while making the transition, but they can go now. Go ahead! > > (Lots of code should disappear along with them!) > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of ?mer Sinan > | Agacan > | Sent: 01 February 2016 22:06 > | To: ghc-devs > | Subject: StgCase - are LiveVars and SRT fields going to be used? > | > | Hi all, > | > | This is how case expression in STG currently defined: > | > | > | | StgCase > | (GenStgExpr bndr occ) > | (GenStgLiveVars occ) > | (GenStgLiveVars occ) > | bndr > | SRT > | AltType > | [GenStgAlt bndr occ] > | > | > | The GenStgLiveVars and SRT fields are never used anywhere in the compiler > | (except the printer). So the question is, I'm assuming those were used at > | some > | point, but are they going to be used in the future? Or can I just delete > | those? > | > | As a proof of concept, I just compiled GHC using this: > | > | > | | StgCase > | (GenStgExpr bndr occ) > | bndr > | AltType > | [GenStgAlt bndr occ] > | > | > | Normally this is not a big deal, but I'm doing lots of STG-to-STG > | transformations nowadays, and I have to keep those field updated which is > | annoying as those are never going to be used (I can't even know if I'm doing > | it > | right), or leave those `undefined` which is not a good practice. > | _______________________________________________ > | 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%7c12ca56c8fc514f477f7f08 > | d32b53f4bc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=LPiupNbUJ9OGL9cmbP%2f > | PAs2JSdxqlxk%2bGbXuYTHFbzg%3d From juhpetersen at gmail.com Tue Feb 2 03:15:21 2016 From: juhpetersen at gmail.com (Jens Petersen) Date: Tue, 2 Feb 2016 12:15:21 +0900 Subject: Dropping bzip2 release tarballs? In-Reply-To: <87r3hl5u60.fsf@smart-cactus.org> References: <87r3hl5u60.fsf@smart-cactus.org> Message-ID: On 14 January 2016 at 01:19, Ben Gamari wrote: > tl;dr do you rely on the .bz2 release tarballs on downloads.haskell.org? I don't have a strong opinion about it and understand the desire to standardize on one archive type. I use the xz src tarballs myself, but how about continuing to do bz2 tarballs of the src tarballs only? (they are about the same size as the xz tarballs anyway) (A lot of small projects even still use tgz... :) Jens From david.feuer at gmail.com Tue Feb 2 03:32:36 2016 From: david.feuer at gmail.com (David Feuer) Date: Mon, 1 Feb 2016 22:32:36 -0500 Subject: Dropping bzip2 release tarballs? In-Reply-To: <87r3hl5u60.fsf@smart-cactus.org> References: <87r3hl5u60.fsf@smart-cactus.org> Message-ID: Does this really strain storage infrastructure? There are only a few blobs per release. If that's really a problem, sufficiently ancient ones can presumably be pruned down to a single format without too many complaints (e.g., if someone wants GHC 7.6, they may not be able to have their choice of format). Bandwidth seems an entirely legitimate concern, but thankfully a symmetric one?most users will want to download the smallest available format, and those who are willing to pay the extra time to download another likely have a good reason. On Wed, Jan 13, 2016 at 11:19 AM, Ben Gamari wrote: > tl;dr do you rely on the .bz2 release tarballs on downloads.haskell.org? > If so, let us know! > > > Hello everyone, > > As you may have noticed, a few releases ago we started producing > xz-compressed binary distributions in addition to the usual bzip2 > tarballs. > > While preparing 8.0.1-rc1 it was suggested that we move to distributing > xz tarballs exclusively. Not only would this move reduce storage and > bandwidth demands on our infrastructure but it would also simplify the > job of producing the distributions. Indeed there is plenty of precendent > for projects who have moved exclusively to xz (the Linux kernel and git > being two examples). > > Of course, these reasons alone aren't sufficient to abandon those who > might rely on our bzip2 tarballs. If you feel strongly that we should > continue to distribute bzip2 tarballs, please let us know. > > Thanks! > > - Your friendly GHC packaging gnomes > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > From juhpetersen at gmail.com Tue Feb 2 09:55:04 2016 From: juhpetersen at gmail.com (Jens Petersen) Date: Tue, 2 Feb 2016 18:55:04 +0900 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: <87twmh5vtk.fsf@smart-cactus.org> References: <87twmh5vtk.fsf@smart-cactus.org> Message-ID: On 14 January 2016 at 00:43, Ben Gamari wrote: > The GHC Team is very pleased to announce the first release candidate of > the Glasgow Haskell Compiler 8.0.1 release. Thanks! - I spent a little trying to build/package it for Fedora, but running in the usual problem with changes in the library paths/package keys handling again... I see that the libraries that come with ghc do not get a package key unlike those built by hand with Cabal (in the hs-libraries field). Hence their filepaths also don't include the key any more. Is this intentional? I need to update my dependency generation script for the libraries. However I am less sure how to handle/get the keys or hashes of dependencies now: is it better to use the id key than the ABI hash? Quite possible that I missed some earlier discussion, but some light on this would be appreciated. Thanks, Jens ps Please ignore: If we could stop changing the library file-paths/-names and hash/key handling so frequently, it would make the life easier for us distro packagers/maintainers, though I am sure there are a good reasons for it. :) From simonpj at microsoft.com Tue Feb 2 11:06:58 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 2 Feb 2016 11:06:58 +0000 Subject: Build failing Message-ID: <073afb54113e4398aa5eba30e6e4b35b@DB4PR30MB030.064d.mgd.msft.net> A clean Windows build fails. See below. help! Simon rts\Linker.c:444:7: error: error: pointer type mismatch in conditional expression [-Werror] : pinfo->owner->fileName ^ rts\Linker.c:429:7: error: error: format '%ls' expects argument of type 'wchar_t *', but argument 4 has type 'void * const' [-Werror=format=] "GHC runtime linker: fatal error: I found a duplicate definition for symbol\n" ^ cc1.exe: all warnings being treated as errors `gcc.exe' failed in phase `C Compiler'. (Exit code: 1) rts/ghc.mk:254: recipe for target 'rts/dist/build/Linker.o' failed make[1]: *** [rts/dist/build/Linker.o] Error 1 make[1]: *** Waiting for unfinished jobs.... Makefile:122: recipe for target 'all' failed make: *** [all] Error 2 /cygdrive/c/code/HEAD$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Tue Feb 2 11:08:36 2016 From: lonetiger at gmail.com (Phyx) Date: Tue, 2 Feb 2016 12:08:36 +0100 Subject: Build failing In-Reply-To: <073afb54113e4398aa5eba30e6e4b35b@DB4PR30MB030.064d.mgd.msft.net> References: <073afb54113e4398aa5eba30e6e4b35b@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Hi Simon, I have made a diff to fix it but it hasn't been reviewed yet https://phabricator.haskell.org/D1878 Regards, Tamar Sent from my Mobile On Feb 2, 2016 12:07 PM, "Simon Peyton Jones" wrote: > A clean Windows build fails. See below. help! > > Simon > > > > rts\Linker.c:444:7: error: > > error: pointer type mismatch in conditional expression [-Werror] > > : pinfo->owner->fileName > > ^ > > > > rts\Linker.c:429:7: error: > > error: format '%ls' expects argument of type 'wchar_t *', but > argument 4 has type 'void * const' [-Werror=format=] > > "GHC runtime linker: fatal error: I found a duplicate > definition for symbol\n" > > ^ > > cc1.exe: all warnings being treated as errors > > `gcc.exe' failed in phase `C Compiler'. (Exit code: 1) > > rts/ghc.mk:254: recipe for target 'rts/dist/build/Linker.o' failed > > make[1]: *** [rts/dist/build/Linker.o] Error 1 > > make[1]: *** Waiting for unfinished jobs.... > > Makefile:122: recipe for target 'all' failed > > make: *** [all] Error 2 > > /cygdrive/c/code/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 ben at smart-cactus.org Tue Feb 2 11:38:46 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 02 Feb 2016 12:38:46 +0100 Subject: Build failing In-Reply-To: References: <073afb54113e4398aa5eba30e6e4b35b@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <871t8vcpfd.fsf@smart-cactus.org> Phyx writes: > Hi Simon, > > I have made a diff to fix it but it hasn't been reviewed yet > https://phabricator.haskell.org/D1878 Thanks Phyx. I just fired off a validation build locally. I'll merge as soon as it passes. 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 Feb 2 12:04:26 2016 From: ben at well-typed.com (Ben Gamari) Date: Tue, 02 Feb 2016 13:04:26 +0100 Subject: Dropping bzip2 release tarballs? In-Reply-To: References: <87r3hl5u60.fsf@smart-cactus.org> Message-ID: <87y4b3b9o5.fsf@smart-cactus.org> David Feuer writes: > Does this really strain storage infrastructure? There are only a few > blobs per release. > To me the real motivation here is to simplify the distribution preparation process. Currently I need to worry about producing, signing, hashing, and uploading two of each tarball. To do this requires a dozen or so lines of bash source that I'd prefer not to have to maintain. It's not the end of the world While our release process is improving, it's unfortunately still a bit finicky. Requirements like having to produce redundant tarballs don't help. I wouldn't say that our storage infrastructure is particularly strained. However, it is a finite resource and if we can use less of it per release at no cost then I think we should. > If that's really a problem, sufficiently ancient ones can presumably > be pruned down to a single format without too many complaints (e.g., > if someone wants GHC 7.6, they may not be able to have their choice of > format). I would not feel comfortable doing this for any release in 7.0 series. Once we put up a distribution, users should be able to expect that it will be there for the foreseeable future. > Bandwidth seems an entirely legitimate concern, but thankfully a > symmetric one?most users will want to download the smallest available > format, and those who are willing to pay the extra time to download > another likely have a good reason. > This is essentially the point I'm trying to make: it appears that essentially everyone uses the xz distributions. If this really is the case, then I would ask why are we spending the disk space, effort, bandwidth, and complexity preparing the bzips. I can't think of a reason why users would prefer bz2 over xz but that of course does not mean that one does not exist. This was the reason for this thread. So far I get the impression that the bzip tarballs will not be missed. 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 Feb 2 12:07:35 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 02 Feb 2016 13:07:35 +0100 Subject: Build failing In-Reply-To: <871t8vcpfd.fsf@smart-cactus.org> References: <073afb54113e4398aa5eba30e6e4b35b@DB4PR30MB030.064d.mgd.msft.net> <871t8vcpfd.fsf@smart-cactus.org> Message-ID: <87vb67b9iw.fsf@smart-cactus.org> Ben Gamari writes: > Phyx writes: > >> Hi Simon, >> >> I have made a diff to fix it but it hasn't been reviewed yet >> https://phabricator.haskell.org/D1878 > > Thanks Phyx. > > I just fired off a validation build locally. I'll merge as soon as it > passes. > It has been merged. Thanks again! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From jan.stolarek at p.lodz.pl Tue Feb 2 12:44:37 2016 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Tue, 2 Feb 2016 13:44:37 +0100 Subject: Dropping bzip2 release tarballs? In-Reply-To: <87y4b3b9o5.fsf@smart-cactus.org> References: <87r3hl5u60.fsf@smart-cactus.org> <87y4b3b9o5.fsf@smart-cactus.org> Message-ID: <201602021344.37661.jan.stolarek@p.lodz.pl> > it appears that essentially everyone uses the xz distributions. If this really is the > case, then I would ask why are we spending the disk space, effort, > bandwidth, and complexity preparing the bzips. I stayed quite in this discusion so far, but I am one of the people still using bz2 rather than xz. Why? Because I use a fairly old Linux distro and my GUI tool for working with archives does not recognize xz format. I'll live without bz2, but my life will be less comfortable. 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 ben at well-typed.com Tue Feb 2 13:20:54 2016 From: ben at well-typed.com (Ben Gamari) Date: Tue, 02 Feb 2016 14:20:54 +0100 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: References: <87twmh5vtk.fsf@smart-cactus.org> Message-ID: <87si1bb64p.fsf@smart-cactus.org> Jens Petersen writes: > On 14 January 2016 at 00:43, Ben Gamari wrote: >> The GHC Team is very pleased to announce the first release candidate of >> the Glasgow Haskell Compiler 8.0.1 release. > > Thanks! - I spent a little trying to build/package it for Fedora, but > running in the usual problem with changes in the library paths/package > keys handling again... > > I see that the libraries that come with ghc do not get a package key > unlike those built by hand with Cabal (in the hs-libraries field). > Hence their filepaths also don't include the key any more. Is this intentional? > > I need to update my dependency generation script for the libraries. > However I am less sure how to handle/get the keys or hashes of > dependencies now: is it better to use the id key than the ABI hash? > Edward, you'd be better able to answer this than me. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From alexander at plaimi.net Tue Feb 2 13:54:27 2016 From: alexander at plaimi.net (Alexander Berntsen) Date: Tue, 2 Feb 2016 14:54:27 +0100 Subject: Best practices for merging? In-Reply-To: References: <56AE4E22.8070502@apeiron.net> <32b958f7b3e5470d8b1fbea913d8cde4@DB4PR30MB030.064d.mgd.msft.net> <87d1sgd14x.fsf@smart-cactus.org> <201602011544.55192.jan.stolarek@p.lodz.pl> <56AF78D2.9000307@apeiron.net> Message-ID: <56B0B513.3010608@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 01/02/16 18:11, Simon Peyton Jones wrote: > The sometimes-torturous history is not of interest to later > readers. I would like to add as a big asterisk to this statement that in practice, big features often break things in subtle ways that are only noticed some time later. It then becomes comparatively trivial to hunt down the error by bisecting ten 25 line commits, when the converse is figuring out a 250+ lines patch. Obligatory "I'm not trying to impose anything". - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWsLUQAAoJENQqWdRUGk8BcN8P/2GVXf9IGjdJGosd/clyGrc/ uqW4+aLmS1jQyhKtbSlHCNA5UaGdB9QvqHLisRZ5itIDM5DqBFurmZwIB48M0csH qGcw9XaT8UuGnaC204+pdROtgW5xo0Ty6P0DvoilDt2NzowYuzpGq8B7CbfCnrhj maxbHG+ZY7YURx8MWeh3pedQC21bcdirppfPcFzjJHs1bwb9GAMgrwqK4LwNWA3B lM0nuoMgujE3tGUTHzAWi88Xe3MFE2seXKlrwSfP7Y0ZrnRmWbGc/Ltc4TfkUyWB dotdaf0NMlcQHyMAybskzrtmpXfMSN6eGrFtjsT220XgTtPG1xG4uHqJETuOh5yJ 9/tTGY8n3YKuCezl26sNjES/W/3jstUfMb8k3p3sqRbvKnJiu5xtGPfboYv6rLN4 B50ZuWIgGCIX2d3b1r09exqlqLvPJp6xGGOwRiCjvcUATNciI1jMXNgeItyeJ33B qm6cvU/1/iQtWfhGEe6HSbOuwO0VFKZ4wG0a1UzGHpBlOoXIhC86ay5Wv2jbutPJ A/4bXKq9w2xDgc75JxIXdM/1DzaZcZ+nHtQ+XNWMUGGbPbxmM2rG+YLfycSAn36q ORpEsRbPCgWmJj+gWftTvYXViDiozqFoMa9cFj0dUjjj8BZ5Qi2egUy4wcTjnhmz FdngEw8YKh9Wq3WF57Bp =sABc -----END PGP SIGNATURE----- From allbery.b at gmail.com Tue Feb 2 14:20:47 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 2 Feb 2016 09:20:47 -0500 Subject: Best practices for merging? In-Reply-To: <56B0B513.3010608@plaimi.net> References: <56AE4E22.8070502@apeiron.net> <32b958f7b3e5470d8b1fbea913d8cde4@DB4PR30MB030.064d.mgd.msft.net> <87d1sgd14x.fsf@smart-cactus.org> <201602011544.55192.jan.stolarek@p.lodz.pl> <56AF78D2.9000307@apeiron.net> <56B0B513.3010608@plaimi.net> Message-ID: On Tue, Feb 2, 2016 at 8:54 AM, Alexander Berntsen wrote: > It then becomes comparatively trivial to hunt > down the error by bisecting ten 25 line commits, when the converse is > figuring out a 250+ lines patch. > Only if it builds and passes tests across all ten commits. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander at plaimi.net Tue Feb 2 14:23:50 2016 From: alexander at plaimi.net (Alexander Berntsen) Date: Tue, 2 Feb 2016 15:23:50 +0100 Subject: Best practices for merging? In-Reply-To: References: <56AE4E22.8070502@apeiron.net> <32b958f7b3e5470d8b1fbea913d8cde4@DB4PR30MB030.064d.mgd.msft.net> <87d1sgd14x.fsf@smart-cactus.org> <201602011544.55192.jan.stolarek@p.lodz.pl> <56AF78D2.9000307@apeiron.net> <56B0B513.3010608@plaimi.net> Message-ID: <56B0BBF6.505@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/02/16 15:20, Brandon Allbery wrote: > Only if it builds and passes tests across all ten commits. Yes, obviously. I have never worked anywhere where breaking commits were allowed, and I did not intend to suggest that breaking commits were a Good Idea or useful. They emphatically aren't. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWsLv1AAoJENQqWdRUGk8BlqoQAL++7E0p4saLgBVeH0Fe15VT rzCb5zd8el+nonR+ln+9bebZ8O7zpnjklDQ3OtcgOLQw5FG+CDVKRnlzKUPds9at hm5EWjDOhHTkIGVeQdW/q5kACr2egR+UDJx15sP7A2uRepkI0SB9r2XyquZuAozK Wswh39x1tp4x4W2SK4ikIgPCezqi05AMrxOX6O1qCUg8lMCJ0b/5VLQ3lNEcIdY9 Qs97Eo78WyNb2C/gqD/V8m3E9RO2X9iB665BsDlsO7pqaDgaas1SORqgOfXf+gFm pjmXUIrmKMvG+EZqGAZbEW1jjZBE0ESnv2C1mM502nwpJL4x3V+htOJruBp9zt+u 3wQJnqNhxiVaCJhUMjvuJFDQrdnyXgYolTDO7VmVtJITBcJODAcG6m3X+maqXvOL JfZcbKXoCO1GTUI+sasD7f78Q1oHBmHBctaD+26aHzDjKkyQ+kTfHi/eo09xVst3 T6VK1ht5NgOXQtMFVW3Bf0z51w56O1M0B+UkER4htIZvOOj85IWvtemzmKzWydlx J1WNjqRg0w5+92B9mvvJfqjCKGakaaVJwBdg6VLLHVszgFfbaTnJ8eI1Kf15izrs eQmrpg40d02wksjtjExdeAC5vs/9QvxYKzF9wr2U5kENLoh214Xy23oD+hMmFE7X k7jlHUrJqTNWAZ07J1MZ =fptS -----END PGP SIGNATURE----- From 0xbadcode at gmail.com Tue Feb 2 14:38:01 2016 From: 0xbadcode at gmail.com (Mathieu Boespflug) Date: Tue, 2 Feb 2016 15:38:01 +0100 Subject: [GHC] #11526: unsafeLookupStaticPtr should not live in IO In-Reply-To: <059.99f4811a0aadc97ebb7454800be69335@haskell.org> References: <044.f93a21b1835068cb7ee01f72ff1b48c6@haskell.org> <059.99f4811a0aadc97ebb7454800be69335@haskell.org> Message-ID: IMHO this dynamic linking thing is a red herring. In principle any function call becomes potentially impure given eg the ability to shadow symbols. In practice that's not something we do to programs. We could consider having two tables though: an initial tackle generated at compile time that will never change, and an aux table populated as new objects get linked in. Then programs can "opt in" to taking into account new objects loaded dynamically by reading (in IO) the aux table. Sent from my mobile. I'll have a look at the new material on the wiki shortly. It would be nice to close out the basic distributed story. -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Tue Feb 2 14:49:06 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 2 Feb 2016 09:49:06 -0500 Subject: Best practices for merging? In-Reply-To: <56B0BBF6.505@plaimi.net> References: <56AE4E22.8070502@apeiron.net> <32b958f7b3e5470d8b1fbea913d8cde4@DB4PR30MB030.064d.mgd.msft.net> <87d1sgd14x.fsf@smart-cactus.org> <201602011544.55192.jan.stolarek@p.lodz.pl> <56AF78D2.9000307@apeiron.net> <56B0B513.3010608@plaimi.net> <56B0BBF6.505@plaimi.net> Message-ID: On Tue, Feb 2, 2016 at 9:23 AM, Alexander Berntsen wrote: > On 02/02/16 15:20, Brandon Allbery wrote: > > Only if it builds and passes tests across all ten commits. > Yes, obviously. I have never worked anywhere where breaking commits > were allowed, and I did not intend to suggest that breaking commits > were a Good Idea or useful. They emphatically aren't. > The point is, this only applies once it's in the ghc repo. Works in progress may well have such commits as long as they are cleaned up on pushing --- which is why you would squash commits together losing intermediate history, which is what started this thread. (This point was actually made earlier in the thread, just not in so many words.) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Tue Feb 2 14:55:03 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Tue, 2 Feb 2016 09:55:03 -0500 Subject: Best practices for merging? In-Reply-To: References: <56AE4E22.8070502@apeiron.net> <32b958f7b3e5470d8b1fbea913d8cde4@DB4PR30MB030.064d.mgd.msft.net> <87d1sgd14x.fsf@smart-cactus.org> <201602011544.55192.jan.stolarek@p.lodz.pl> <56AF78D2.9000307@apeiron.net> <56B0B513.3010608@plaimi.net> <56B0BBF6.505@plaimi.net> Message-ID: What if there were an official place to keep dirty histories? For example, my TypeInType patch has a very long, very tortuous history. Probably the majority of commits don't compile. (On a development branch meant for private use, I see no good reason to insist that each commit builds.) I would never want that history to join the main repo. But I've made sure that I keep access to it, just in case. It's all publicly available on github. The problem is that only I know where to find it. If we had an official "dump your dirty history here" repo, perhaps that would be helpful when disaster strikes. Richard On Feb 2, 2016, at 9:49 AM, Brandon Allbery wrote: > > On Tue, Feb 2, 2016 at 9:23 AM, Alexander Berntsen wrote: > On 02/02/16 15:20, Brandon Allbery wrote: > > Only if it builds and passes tests across all ten commits. > Yes, obviously. I have never worked anywhere where breaking commits > were allowed, and I did not intend to suggest that breaking commits > were a Good Idea or useful. They emphatically aren't. > > The point is, this only applies once it's in the ghc repo. Works in progress may well have such commits as long as they are cleaned up on pushing --- which is why you would squash commits together losing intermediate history, which is what started this thread. (This point was actually made earlier in the thread, just not in so many words.) > > -- > brandon s allbery kf8nh sine nomine associates > allbery.b at gmail.com ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net > _______________________________________________ > 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 allbery.b at gmail.com Tue Feb 2 14:58:53 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 2 Feb 2016 09:58:53 -0500 Subject: Best practices for merging? In-Reply-To: References: <56AE4E22.8070502@apeiron.net> <32b958f7b3e5470d8b1fbea913d8cde4@DB4PR30MB030.064d.mgd.msft.net> <87d1sgd14x.fsf@smart-cactus.org> <201602011544.55192.jan.stolarek@p.lodz.pl> <56AF78D2.9000307@apeiron.net> <56B0B513.3010608@plaimi.net> <56B0BBF6.505@plaimi.net> Message-ID: On Tue, Feb 2, 2016 at 9:55 AM, Richard Eisenberg wrote: > What if there were an official place to keep dirty histories? git actually has a place for these, although at a price: when you squash commits or otherwise modify history, the originals are retained in the reflog. By default the reflog gets cleaned periodically, and letting it grow without bound has a performance impact, but in theory it could be used to keep this information. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Feb 2 15:08:26 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 2 Feb 2016 15:08:26 +0000 Subject: [GHC] #11526: unsafeLookupStaticPtr should not live in IO In-Reply-To: References: <044.f93a21b1835068cb7ee01f72ff1b48c6@haskell.org> <059.99f4811a0aadc97ebb7454800be69335@haskell.org> Message-ID: Fine. So long as the result of deserialising doesn?t change with time! It?s not clear what the ?opt-in? mechanism would look like, but maybe you or Facundo can articulate a design? S From: Mathieu Boespflug [mailto:0xbadcode at gmail.com] Sent: 02 February 2016 14:38 To: ghc-devs at haskell.org; Simon Peyton Jones ; Edsko de Vries ; Facundo Dom?nguez Subject: Re: [GHC] #11526: unsafeLookupStaticPtr should not live in IO IMHO this dynamic linking thing is a red herring. In principle any function call becomes potentially impure given eg the ability to shadow symbols. In practice that's not something we do to programs. We could consider having two tables though: an initial tackle generated at compile time that will never change, and an aux table populated as new objects get linked in. Then programs can "opt in" to taking into account new objects loaded dynamically by reading (in IO) the aux table. Sent from my mobile. I'll have a look at the new material on the wiki shortly. It would be nice to close out the basic distributed story. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Tue Feb 2 18:50:11 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 02 Feb 2016 19:50:11 +0100 Subject: CallStack naming In-Reply-To: <3086447f86064970bd1be9b1e62045f3@DB4PR30MB030.064d.mgd.msft.net> References: <96F502AD-4AC6-40FA-BD9C-C9C063C2DDE0@cis.upenn.edu> <659dc968669143e0972602a72fb7753e@DB4PR30MB030.064d.mgd.msft.net> <1453305947.1797061.497600914.32732A90@webmail.messagingengine.com> <13f3ddc1d01a4f46ac15a051cc8ff049@DB4PR30MB030.064d.mgd.msft.net> <1453310647.1815559.497698170.68A46486@webmail.messagingengine.com> <1453367951.23159.6.camel@joachim-breitner.de> <1453918574.415584.504305722.15570A0D@webmail.messagingengine.com> <3086447f86064970bd1be9b1e62045f3@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <87lh73aqvw.fsf@smart-cactus.org> Simon Peyton Jones writes: > OK. Let's make sure the wiki page and documentation reflects this. > It looks like the Wiki [1] hasn't yet been updated. Let's make sure this happens. Thanks! - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/ExplicitCallStack/ImplicitLocations -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From eir at cis.upenn.edu Tue Feb 2 21:33:33 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Tue, 2 Feb 2016 16:33:33 -0500 Subject: PrimRep constructor Vec Message-ID: <509C0DC1-658A-47DB-8431-F603A4FDCA11@cis.upenn.edu> Hi Geoff, I'm working on the fix for #11471, which involves interacting with the PrimRep type. (You don't need the ticket background to understand this question, though.) One of PrimRep's constructors is VecRep, which Simon tells me is your domain. The problem is that I can find nowhere in the source code where this constructor is used. I see several consumers, but no producers. Is this constructor now unused? Should I remove it? Thanks, Richard From simonpj at microsoft.com Wed Feb 3 12:38:15 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 3 Feb 2016 12:38:15 +0000 Subject: PrimRep constructor Vec In-Reply-To: <509C0DC1-658A-47DB-8431-F603A4FDCA11@cis.upenn.edu> References: <509C0DC1-658A-47DB-8431-F603A4FDCA11@cis.upenn.edu> Message-ID: <49a60a5c80234eb5aa78fd53cdbb8dd2@DB4PR30MB030.064d.mgd.msft.net> I think it may appear in code generated from primops.txt Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Richard Eisenberg | Sent: 02 February 2016 21:34 | To: Geoffrey Mainland | Cc: ghc-devs at haskell.org developers | Subject: PrimRep constructor Vec | | Hi Geoff, | | I'm working on the fix for #11471, which involves interacting with the | PrimRep type. (You don't need the ticket background to understand this | question, though.) One of PrimRep's constructors is VecRep, which Simon | tells me is your domain. The problem is that I can find nowhere in the | source code where this constructor is used. I see several consumers, | but no producers. Is this constructor now unused? Should I remove it? | | Thanks, | Richard | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha | skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cec3894b071464230 | fccb08d32c329ccf%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=DxmEqogqU | v7A%2bridzwWEEF6bz6mBMhFj9KDmL4y98iU%3d From voldermort at hotmail.com Wed Feb 3 15:35:52 2016 From: voldermort at hotmail.com (Nonce .) Date: Wed, 3 Feb 2016 15:35:52 +0000 Subject: Adding a "release" setting in build.mk.sample (and some other build system questions) In-Reply-To: References: , Message-ID: > Date: Fri, 29 Jan 2016 17:44:56 +0100 > Subject: Re: Adding a "release" setting in build.mk.sample (and some > other build system questions) > From: thomasmiedema at gmail.com > To: voldermort at hotmail.com > CC: ghc-devs at haskell.org > > The default (and thus release) `SRC_HC_OPTS` uses `-H32m` (see > mk/config.mk.in). > > Maybe you want to run some tests to see if it makes a difference on the > total build time? > > I suggest also measuring without any `-H` flag, with just `-H` (see > commit below), and with `-H1G` or some other large value. > > ``` > commit 323950933d3260503186b93e7a5a7bdaa4822c1b > Author: Simon Marlow > > Date: Mon Nov 30 15:18:36 2009 +0000 > > Implement a new heap-tuning option: -H > > -H alone causes the RTS to use a larger nursery, but without exceeding > the amount of memory that the application is already using. It trades > off GC time against locality: the default setting is to use a > fixed-size 512k nursery, but this is sometimes worse than using a very > large nursery despite the worse locality. > > Not all programs get faster, but some programs that use large heaps do > much better with -H. e.g. this helps a lot with #3061 (binary-trees), > though not as much as specifying -H. Typically using -H > is better than plain -H, because the runtime doesn't know ahead of > time how much memory you want to use. > > Should -H be on by default? I'm not sure, it makes some programs go > slower, but others go faster. For reference, there is some discussion in https://mail.haskell.org/pipermail/ghc-devs/2014-March/004344.html. Perhaps all of the -H options should be dropped from config.mk.in and the various build flavours, until it can be shown that some value is better than GHC's defaults for the overwhelming majority of builders? Even if I could show that some value works better for me, that doesn't mean it will work better for you or anyone else. From simonpj at microsoft.com Wed Feb 3 16:47:38 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 3 Feb 2016 16:47:38 +0000 Subject: Specializing expressions beyond names? In-Reply-To: References: Message-ID: <40d34aef92874089a8f1e68ec4c15a7e@DB4PR30MB030.064d.mgd.msft.net> I?m sorry Conal I?m not getting this. Specialisation happens when you have a named chunk of code that is repeatedly called at different types, and with different args. We can inline it bodily to specialise to that one call site, but it?s cooler to make a single specialised version which can be shared among many call sites. (And that approach deals with recursive functions too.) But that explanation is fundamentally about named functions, so I don?t understand this ?general expression? bit. Sorry! Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Conal Elliott Sent: 01 February 2016 01:16 To: ghc-devs at haskell.org Subject: Re: Specializing expressions beyond names? A related question: if there are a great many rules of the form "reify (foo ...) = ...", where 'reify' is always present (and the outermost application head) but for many different argument expressions, will rule matching be linear (expensive) in the number of such rules? -- Conal On Sun, Jan 31, 2016 at 1:58 PM, Conal Elliott > wrote: It seems to be the case that SPECIALIZE pragmas are syntactically restricted to type specializations of a name (identifier) rather than a general expression. Is my understanding correct here? If so, is there any reason for this restriction? I ask because I?m reifying Core code (into code that constructs a corresponding run-time representation for further processing), and I?m looking for a clean way to integrate that process with GHC, to support separate compilation and to avoid interfering with GHC?s regular flow. It occurred to me that I could enable separate compilation via a pragma of the form ?{-# SPECIALIZE reify foo ? E t #-}? for some t, where E t is a reified form of values of type t. Type checking would infer the specialized type of foo, and the usual specialization phase would do its usual thing on that specialization, leaving ?reify foo = reify specialized_foo?, and then the reification compiler plugin would transform the right-hand side, pushing the reify inward. Some reify calls may remain (e.g., due to polymorphism), triggering future rule applications. As much as possible of the fully-reified version would be factored out of the generated rule?s RHS for cheap reuse. Thanks, - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: From mainland at drexel.edu Wed Feb 3 17:10:06 2016 From: mainland at drexel.edu (Geoffrey Mainland) Date: Wed, 3 Feb 2016 12:10:06 -0500 Subject: PrimRep constructor Vec In-Reply-To: <49a60a5c80234eb5aa78fd53cdbb8dd2@DB4PR30MB030.064d.mgd.msft.net> References: <509C0DC1-658A-47DB-8431-F603A4FDCA11@cis.upenn.edu> <49a60a5c80234eb5aa78fd53cdbb8dd2@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <56B2346E.8010901@drexel.edu> Indeed, the producer is utils/genprimopcode/Main.hs. Check out compiler/stage1/build/primop-vector-tys.hs-incl in your build tree---should be plenty of generated VecRep's there :) Cheers, Geoff On 02/03/2016 07:38 AM, Simon Peyton Jones wrote: > I think it may appear in code generated from primops.txt > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of > | Richard Eisenberg > | Sent: 02 February 2016 21:34 > | To: Geoffrey Mainland > | Cc: ghc-devs at haskell.org developers > | Subject: PrimRep constructor Vec > | > | Hi Geoff, > | > | I'm working on the fix for #11471, which involves interacting with the > | PrimRep type. (You don't need the ticket background to understand this > | question, though.) One of PrimRep's constructors is VecRep, which Simon > | tells me is your domain. The problem is that I can find nowhere in the > | source code where this constructor is used. I see several consumers, > | but no producers. Is this constructor now unused? Should I remove it? > | > | Thanks, > | Richard > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha > | skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- > | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cec3894b071464230 > | fccb08d32c329ccf%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=DxmEqogqU > | v7A%2bridzwWEEF6bz6mBMhFj9KDmL4y98iU%3d > From simonpj at microsoft.com Wed Feb 3 17:10:55 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 3 Feb 2016 17:10:55 +0000 Subject: PrimRep constructor Vec In-Reply-To: <56B2346E.8010901@drexel.edu> References: <509C0DC1-658A-47DB-8431-F603A4FDCA11@cis.upenn.edu> <49a60a5c80234eb5aa78fd53cdbb8dd2@DB4PR30MB030.064d.mgd.msft.net> <56B2346E.8010901@drexel.edu> Message-ID: Thanks. A Note somewhere would be good!!! | -----Original Message----- | From: Geoffrey Mainland [mailto:mainland at drexel.edu] | Sent: 03 February 2016 17:10 | To: Simon Peyton Jones ; Richard Eisenberg | | Cc: ghc-devs at haskell.org developers | Subject: Re: PrimRep constructor Vec | | Indeed, the producer is utils/genprimopcode/Main.hs. | | Check out compiler/stage1/build/primop-vector-tys.hs-incl in your build | tree---should be plenty of generated VecRep's there :) | | Cheers, | Geoff | | On 02/03/2016 07:38 AM, Simon Peyton Jones wrote: | > I think it may appear in code generated from primops.txt | > | > Simon | > | > | -----Original Message----- | > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | > | Richard Eisenberg | > | Sent: 02 February 2016 21:34 | > | To: Geoffrey Mainland | > | Cc: ghc-devs at haskell.org developers | > | Subject: PrimRep constructor Vec | > | | > | Hi Geoff, | > | | > | I'm working on the fix for #11471, which involves interacting with | > | the PrimRep type. (You don't need the ticket background to | > | understand this question, though.) One of PrimRep's constructors | is | > | VecRep, which Simon tells me is your domain. The problem is that I | > | can find nowhere in the source code where this constructor is | used. | > | I see several consumers, but no producers. Is this constructor now | unused? Should I remove it? | > | | > | Thanks, | > | Richard | > | _______________________________________________ | > | ghc-devs mailing list | > | ghc-devs at haskell.org | > | | > | | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail | > | .ha | > | skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | > | | > | | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cec3894b071464 | > | 230 | > | | fccb08d32c329ccf%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=DxmEqo | > | gqU v7A%2bridzwWEEF6bz6mBMhFj9KDmL4y98iU%3d | > | From eric at seidel.io Wed Feb 3 18:07:00 2016 From: eric at seidel.io (Eric Seidel) Date: Wed, 03 Feb 2016 10:07:00 -0800 Subject: CallStack naming In-Reply-To: <87lh73aqvw.fsf@smart-cactus.org> References: <96F502AD-4AC6-40FA-BD9C-C9C063C2DDE0@cis.upenn.edu> <659dc968669143e0972602a72fb7753e@DB4PR30MB030.064d.mgd.msft.net> <1453305947.1797061.497600914.32732A90@webmail.messagingengine.com> <13f3ddc1d01a4f46ac15a051cc8ff049@DB4PR30MB030.064d.mgd.msft.net> <1453310647.1815559.497698170.68A46486@webmail.messagingengine.com> <1453367951.23159.6.camel@joachim-breitner.de> <1453918574.415584.504305722.15570A0D@webmail.messagingengine.com> <3086447f86064970bd1be9b1e62045f3@DB4PR30MB030.064d.mgd.msft.net> <87lh73aqvw.fsf@smart-cactus.org> Message-ID: <1454522820.594110.511015986.25444631@webmail.messagingengine.com> Thanks for the reminder! I've added a section [1] on setCallStack with my explanation from above. [1]: https://ghc.haskell.org/trac/ghc/wiki/ExplicitCallStack/ImplicitLocations#GeneralizingtosetCallStack On Tue, Feb 2, 2016, at 10:50, Ben Gamari wrote: > Simon Peyton Jones writes: > > > OK. Let's make sure the wiki page and documentation reflects this. > > > It looks like the Wiki [1] hasn't yet been updated. Let's make sure this > happens. > > Thanks! > > - Ben > > > [1] > https://ghc.haskell.org/trac/ghc/wiki/ExplicitCallStack/ImplicitLocations > Email had 1 attachment: > + signature.asc > 1k (application/pgp-signature) From cma at bitemyapp.com Wed Feb 3 23:30:21 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Wed, 3 Feb 2016 17:30:21 -0600 Subject: Guarantees for ST and IO shared in common? Message-ID: Underlying ST is: GHC.Prim.State# s -> (# GHC.Prim.State# s, a #) Underlying IO is: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, a #) Based on the (very helpful!) conversation I had on the #ghc IRC channel, it seems to me that the mechanism for preventing things like reordering operations or spurious sharing is shared in common between ST and IO via State#. Is this accurate? I believe the exception is how RealWorld is used w/ IO but we can put that off for this question. If anyone could confirm this understanding that would be helpful. If anyone could point out exceptions to this notion, I'd very much appreciate that as well. Thanks again for everyone's time. -- Chris Allen Currently working on http://haskellbook.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From conal at conal.net Thu Feb 4 06:14:49 2016 From: conal at conal.net (Conal Elliott) Date: Wed, 3 Feb 2016 22:14:49 -0800 Subject: Specializing expressions beyond names? In-Reply-To: <40d34aef92874089a8f1e68ec4c15a7e@DB4PR30MB030.064d.mgd.msft.net> References: <40d34aef92874089a8f1e68ec4c15a7e@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Hi Simon. Thanks for the reply. Below, I try to explain more clearly what I want and why below. If it?s still murky, and if you?re up for it, a Skype chat would probably help a lot. I think I?m looking for something very close to GHC?s specialization as it is now, and I?m wondering how to best leverage the specialization that GHC already does. I have a GHC plugin that transforms Core programs into reifying versions of themselves. The transformation is triggered by application of a ?function? reify ? a ? E a for an expression GADT). reify is more like a macro, in that its implementation relies on the (Core) syntax of its argument, not just its semantics, but in a well-behaved way (with a simple, non-syntactic specification). This reifying transformation benefits from the dictionary elimination that GHC?s specializer performs, and I?d like to benefit more. After specialization, or as part of it, I want to reuse the work of reifying the specialized definition. Currently I have to inline the code generated by the specializer, across modules (and assuming that its code is available), and then reify it at each call site. I?d rather have the option to reify specializations in the defining module and then reuse those reified specializations at call-sites, even in other modules. Thus, I don?t want to specialize a function foo at various types, but the result of transforming reify foo for those types, hence my interest in specializing expressions at least a bit more complicated than identifiers. I expect that this scheme, or something like it, will let me eliminate much inlining of code from other modules and then reifying these large expressions. In other words, it lets me do ?separate reification? akin to separate compilation. Perhaps I should be thinking of specializing reifications instead of reifying specializations. I guess that alternative would mean having the specializer perform reification (using a few CoreExpr rewrites) as part of the work it does. Given foo ? T (where T may include polymorphism and dictionaries), I might generate reify_foo ? E Treify_foo = reify foo and then transform the RHS to remove the reify call, resulting in E-building Core code. Then request specializations for reify_foo. The types are not quite this simple, due to polymorphism and dictionaries. For instance, given sum ? (Foldable f, Num a) ? f a ? a generate reify_sum ? (Foldable f, Num a) ? E (f a ? a) reify_sum = reify sum In Core, reify_sum ? ? f a. Foldable f ? Num a ? E (f a ? a) reify_sum = ? (@ f) (@ a) ($dFoldable ? Foldable f) ($dNum ? Num a) ? reify (sum @ f @ a $dFoldable $dNum) Then ask for specializations of reify_sum. Since reification all happens invisibly, reify_sum won?t ever get called in client code. Instead, I?d have to also recognize calls to reify sum from other modules and replace those calls with reify_sum. Oh. Hm. Perhaps the specializer doesn?t have to invoke the reifier after all. Maybe I can generate definitions like reify_sum and some SPECIALIZE pragmas (or directly invoke the equivalent code GHC), and then reify the results after the specializer runs. I?ve started down a path of doing something similar: - Wait until the specializer has run. - Reify all top-level definitions I?m able to, adding new reifying definitions and reify rules that use those new definitions (as the specializer does). Here?s where I?m worried about the efficiency of having many rules with the same RHS top-level identifier. - Apply those rules in other modules during reification, pushing reify calls inward where they can meet up with other functions also reify rules from other modules. Because I?m worried about the performance with many reify rules, maybe I?ll drop the rules and instead export definitions like reify_sum (after reify-transforming the RHS), with predictable names, and then explicitly look for those names across modules during reification. Or does GHC handle that situation well, as long there are few uses (probably only one use) of each name that reify is applied to in these rules (thanks to the specializer having already run, yielding many differently named specializations). As I mentioned, a Skype chat may be helpful. Best regards, - Conal On Wed, Feb 3, 2016 at 8:47 AM, Simon Peyton Jones wrote: > I?m sorry Conal I?m not getting this. > > > > Specialisation happens when you have a named chunk of code that is > repeatedly called at different types, and with different args. We can > inline it bodily to specialise to that one call site, but it?s cooler to > make a single specialised version which can be shared among many call > sites. (And that approach deals with recursive functions too.) > > > > But that explanation is fundamentally about named functions, so I don?t > understand this ?general expression? bit. Sorry! > > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Conal > Elliott > *Sent:* 01 February 2016 01:16 > *To:* ghc-devs at haskell.org > *Subject:* Re: Specializing expressions beyond names? > > > > A related question: if there are a great many rules of the form "reify > (foo ...) = ...", where 'reify' is always present (and the outermost > application head) but for many different argument expressions, will rule > matching be linear (expensive) in the number of such rules? > > -- Conal > > > > On Sun, Jan 31, 2016 at 1:58 PM, Conal Elliott wrote: > > It seems to be the case that SPECIALIZE pragmas are syntactically > restricted to type specializations of a *name* (identifier) rather than a > general expression. Is my understanding correct here? If so, is there any > reason for this restriction? > > I ask because I?m reifying Core code (into code that constructs a > corresponding run-time representation for further processing), and I?m > looking for a clean way to integrate that process with GHC, to support > separate compilation and to avoid interfering with GHC?s regular flow. It > occurred to me that I could enable separate compilation via a pragma of the > form ?{-# SPECIALIZE reify foo ? E t #-}? for some t, where E t is a > reified form of values of type t. Type checking would infer the > specialized type of foo, and the usual specialization phase would do its > usual thing on that specialization, leaving ?reify foo = reify > specialized_foo?, and then the reification compiler plugin would > transform the right-hand side, pushing the reify inward. Some reify calls > may remain (e.g., due to polymorphism), triggering future rule > applications. As much as possible of the fully-reified version would be > factored out of the generated rule?s RHS for cheap reuse. > > > > Thanks, - Conal > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Feb 4 12:11:14 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 4 Feb 2016 12:11:14 +0000 Subject: Guarantees for ST and IO shared in common? In-Reply-To: References: Message-ID: <53e30cd5bc40480faf01bda8fb857fce@DB4PR30MB030.064d.mgd.msft.net> that the mechanism for preventing things like reordering operations or spurious sharing is shared in common between ST and IO via State# Yes. It?s pure data dependency, no more and no less. Operations in both ST and IO take a State# token as input, and produce one as output. So of course to get the input one, all preceding operations must be done first. Simple! Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Christopher Allen Sent: 03 February 2016 23:30 To: ghc-devs at haskell.org Subject: Guarantees for ST and IO shared in common? Underlying ST is: GHC.Prim.State# s -> (# GHC.Prim.State# s, a #) Underlying IO is: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, a #) Based on the (very helpful!) conversation I had on the #ghc IRC channel, it seems to me that the mechanism for preventing things like reordering operations or spurious sharing is shared in common between ST and IO via State#. Is this accurate? I believe the exception is how RealWorld is used w/ IO but we can put that off for this question. If anyone could confirm this understanding that would be helpful. If anyone could point out exceptions to this notion, I'd very much appreciate that as well. Thanks again for everyone's time. -- Chris Allen Currently working on http://haskellbook.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From g9ks157k at acme.softbase.org Thu Feb 4 12:19:45 2016 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu, 04 Feb 2016 14:19:45 +0200 Subject: Automatically deriving Generic for every algebraic data type Message-ID: <1454588385.24363.7.camel@idefix> Hi, if you do generic programming these days, you can use DeriveAnyClass to write code like the following (where Serializable is a class with a generic default implementation): > data Tree a = Leaf | Branch (Tree a) a (Tree a) > deriving (Generic, Serializable) It would be great, if you could just write the following instead: > data Tree a = Leaf | Branch (Tree a) a (Tree a) deriving Serializable This would correspond exactly to what you do when using standard Haskell deriving. It could be made possible by letting the compiler instantiate the Generic class automatically every time an algebraic data type is declared. A potential downside of this would be that programmers would not be able to define non-standard instances of Generics, but I actually cannot see that this is very useful anyhow. Any comments? All the best, Wolfgang From g9ks157k at acme.softbase.org Thu Feb 4 12:28:16 2016 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu, 04 Feb 2016 14:28:16 +0200 Subject: Automatically deriving Generic for every algebraic data type In-Reply-To: <1454588385.24363.7.camel@idefix> References: <1454588385.24363.7.camel@idefix> Message-ID: <1454588896.24363.14.camel@idefix> Am Donnerstag, den 04.02.2016, 14:19 +0200 schrieb Wolfgang Jeltsch: > Hi, > > if you do generic programming these days, you can use DeriveAnyClass to > write code like the following (where Serializable is a class with a > generic default implementation): > > > data Tree a = Leaf | Branch (Tree a) a (Tree a) > > deriving (Generic, Serializable) > > It would be great, if you could just write the following instead: > > > data Tree a = Leaf | Branch (Tree a) a (Tree a) deriving Serializable > > This would correspond exactly to what you do when using standard Haskell > deriving. It could be made possible by letting the compiler instantiate > the Generic class automatically every time an algebraic data type is > declared. A potential downside of this would be that programmers would > not be able to define non-standard instances of Generics, but I actually > cannot see that this is very useful anyhow. I want to add that this would probably allow us to implement all the other deriving mechanisms (for standard classes, for Functor, etc.) entirely in libraries, using generic programming, without forcing users to change their code by adding deriving of Generic. Maybe a future standard Haskell would not even have deriving rules hardwired into the language anymore (which always felt somehow wrong to me). Wouldn?t this be great? ;-) All the best, Wolfgang From oleg.grenrus at iki.fi Thu Feb 4 13:17:34 2016 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Thu, 4 Feb 2016 15:17:34 +0200 Subject: Automatically deriving Generic for every algebraic data type In-Reply-To: <1454588896.24363.14.camel@idefix> References: <1454588385.24363.7.camel@idefix> <1454588896.24363.14.camel@idefix> Message-ID: <05469C3B-F431-427A-85C6-BF17D3B2A02C@iki.fi> Hi, sometimes I want to use Generic derivation, but don?t want expose the Generic instance outside the module. The reason, is that for some types I want to export only smart constructors / modifier lenses; yet the structure is probably simple enough to benefit from `Generic`. If it will be possible to restrict export of the Generic instance, then I don?t see problem of auto-deriving it for everything possible though. - Oleg > On 04 Feb 2016, at 14:28, Wolfgang Jeltsch wrote: > > > Am Donnerstag, den 04.02.2016, 14:19 +0200 schrieb Wolfgang Jeltsch: >> Hi, >> >> if you do generic programming these days, you can use DeriveAnyClass to >> write code like the following (where Serializable is a class with a >> generic default implementation): >> >>> data Tree a = Leaf | Branch (Tree a) a (Tree a) >>> deriving (Generic, Serializable) >> >> It would be great, if you could just write the following instead: >> >>> data Tree a = Leaf | Branch (Tree a) a (Tree a) deriving Serializable >> >> This would correspond exactly to what you do when using standard Haskell >> deriving. It could be made possible by letting the compiler instantiate >> the Generic class automatically every time an algebraic data type is >> declared. A potential downside of this would be that programmers would >> not be able to define non-standard instances of Generics, but I actually >> cannot see that this is very useful anyhow. > > I want to add that this would probably allow us to implement all the > other deriving mechanisms (for standard classes, for Functor, etc.) > entirely in libraries, using generic programming, without forcing users > to change their code by adding deriving of Generic. Maybe a future > standard Haskell would not even have deriving rules hardwired into the > language anymore (which always felt somehow wrong to me). Wouldn?t this > be great? ;-) > > All the best, > Wolfgang > > > _______________________________________________ > 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: -------------- 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 ryan.gl.scott at gmail.com Thu Feb 4 14:20:00 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Thu, 4 Feb 2016 09:20:00 -0500 Subject: Automatically deriving Generic for every algebraic data type Message-ID: I'm a pretty solid -1 on this idea. On a general level, I'm opposed to the idea of deriving typeclasses without the programmer opting in. Most typeclasses express operations that your datatype must support, and in the case of Generic(1), it mandates that users can convert between values of your datatype and an isomorphic representation type. As Oleg noted, this completely destroys encapsulation for datatypes whose constructors you don't want to export. Another issue is the nontrivial cost of automatic derivation. Typeclasses can be surprisingly expensive to derive. About a year ago, Reid Barton measured the amount of increase in code size that each derivable typeclass contributes [1], and Generic was far and away the most expensive one. There's also the issue that deriving Generic on large datatypes can drastically increase the amount of memory needed during compilation [2]. Yet another problem is that deriving Generic1 simply doesn't work for every datatype. Not only does deriving Generic1 not work with sophisticated language features (e.g., -XExistentialQuantification [3]) by design, but there are still a number of outstanding bugs that prevent legitimate Generic1 from being deriving automatically. For example, the following datatype: newtype Compose (f :: k1 -> *) (g :: k2 -> k1) (a :: k2) = Compose (f (g a)) chokes when attempting to derive Generic1 automatically [4]. You have to hack around this by using -XStandaloneDeriving with a programmer-specified instance context. One could imagine a compromise in which Generic(1) would not be derived for datatypes for which attempting to derive those classes yields an error. But I would argue that this is very undesirable, since programmers would just expect every datatype to work out of the box with Generic(1), only to find "Cannot find instance Generic1 Compose"-like errors when they try using Generic1 operations on datatypes that trip the bug mentioned in [4]. There are exceptions to the don't-derive-typeclasses-automatically rule, with Typeable being a notable example [5]. But deriving Typeable has the benefit that (1) it doesn't impose many requirements on your datatype (other than you can get a TypeRep for it), (2) it's cheap to derive (see the table in [1]), and (3) it works on literally every datatype. Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/9557#comment:8 [2] https://ghc.haskell.org/trac/ghc/ticket/5642 [3] https://ghc.haskell.org/trac/ghc/ticket/10514 [4] https://ghc.haskell.org/trac/ghc/ticket/10524#comment:16 [5] https://ghc.haskell.org/trac/ghc/ticket/8950 From roma at ro-che.info Thu Feb 4 14:21:18 2016 From: roma at ro-che.info (Roman Cheplyaka) Date: Thu, 4 Feb 2016 16:21:18 +0200 Subject: Automatically deriving Generic for every algebraic data type In-Reply-To: <1454588385.24363.7.camel@idefix> References: <1454588385.24363.7.camel@idefix> Message-ID: <56B35E5E.3050702@ro-che.info> On 02/04/2016 02:19 PM, Wolfgang Jeltsch wrote: > Hi, > > if you do generic programming these days, you can use DeriveAnyClass to > write code like the following (where Serializable is a class with a > generic default implementation): > >> data Tree a = Leaf | Branch (Tree a) a (Tree a) >> deriving (Generic, Serializable) > > It would be great, if you could just write the following instead: > >> data Tree a = Leaf | Branch (Tree a) a (Tree a) deriving Serializable > > This would correspond exactly to what you do when using standard Haskell > deriving. It could be made possible by letting the compiler instantiate > the Generic class automatically every time an algebraic data type is > declared. A potential downside of this would be that programmers would > not be able to define non-standard instances of Generics, but I actually > cannot see that this is very useful anyhow. > > Any comments? GHC.Generics already have an unfair advantage over the alternative (and arguably, superior) libraries, such as generics-sop. I wouldn't want to give it even more special treatment than it receives right now. Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From andres.loeh at gmail.com Thu Feb 4 14:27:16 2016 From: andres.loeh at gmail.com (=?UTF-8?Q?Andres_L=C3=B6h?=) Date: Thu, 4 Feb 2016 15:27:16 +0100 Subject: Automatically deriving Generic for every algebraic data type In-Reply-To: References: Message-ID: I agree with Ryan on this, i.e., a general automatic DeriveGeneric would not be a good idea right now. Note also that it is already the case that if you want to derive certain classes, you may have to derive other classes as well, namely if superclasses are involved. So you cannot say "deriving Ord", but rather have to say "deriving (Eq, Ord)". In this sense, I don't think the situation with "Serialize" is that much worse. An AutoDeriveGeneric language extension that can be enabled for particular modules might be a possible compromise I could live with. I think it is worth thinking more generally about a replacement for "deriving" that has the chance of making different approaches feel more similar. I'm not overly happy with the current situation wrt DeriveAnyClass and the way conflicts between built-in, newtype- and anyclass-deriving are resolved. Cheers, Andres On Thu, Feb 4, 2016 at 3:20 PM, Ryan Scott wrote: > I'm a pretty solid -1 on this idea. > > On a general level, I'm opposed to the idea of deriving typeclasses > without the programmer opting in. Most typeclasses express operations > that your datatype must support, and in the case of Generic(1), it > mandates that users can convert between values of your datatype and an > isomorphic representation type. As Oleg noted, this completely > destroys encapsulation for datatypes whose constructors you don't want > to export. > > Another issue is the nontrivial cost of automatic derivation. > Typeclasses can be surprisingly expensive to derive. About a year ago, > Reid Barton measured the amount of increase in code size that each > derivable typeclass contributes [1], and Generic was far and away the > most expensive one. There's also the issue that deriving Generic on > large datatypes can drastically increase the amount of memory needed > during compilation [2]. > > Yet another problem is that deriving Generic1 simply doesn't work for > every datatype. Not only does deriving Generic1 not work with > sophisticated language features (e.g., -XExistentialQuantification > [3]) by design, but there are still a number of outstanding bugs that > prevent legitimate Generic1 from being deriving automatically. For > example, the following datatype: > > newtype Compose (f :: k1 -> *) (g :: k2 -> k1) (a :: k2) = Compose (f (g a)) > > chokes when attempting to derive Generic1 automatically [4]. You have > to hack around this by using -XStandaloneDeriving with a > programmer-specified instance context. > > One could imagine a compromise in which Generic(1) would not be > derived for datatypes for which attempting to derive those classes > yields an error. But I would argue that this is very undesirable, > since programmers would just expect every datatype to work out of the > box with Generic(1), only to find "Cannot find instance Generic1 > Compose"-like errors when they try using Generic1 operations on > datatypes that trip the bug mentioned in [4]. > > There are exceptions to the don't-derive-typeclasses-automatically > rule, with Typeable being a notable example [5]. But deriving Typeable > has the benefit that (1) it doesn't impose many requirements on your > datatype (other than you can get a TypeRep for it), (2) it's cheap to > derive (see the table in [1]), and (3) it works on literally every > datatype. > > Ryan S. > ----- > [1] https://ghc.haskell.org/trac/ghc/ticket/9557#comment:8 > [2] https://ghc.haskell.org/trac/ghc/ticket/5642 > [3] https://ghc.haskell.org/trac/ghc/ticket/10514 > [4] https://ghc.haskell.org/trac/ghc/ticket/10524#comment:16 > [5] https://ghc.haskell.org/trac/ghc/ticket/8950 > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From cma at bitemyapp.com Thu Feb 4 18:21:23 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Thu, 4 Feb 2016 12:21:23 -0600 Subject: New type of ($) operator in GHC 8.0 is problematic Message-ID: $ ghci :lGHCi, version 8.0.0.20160122: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/callen/.ghci Prelude> :t ($) ($) :: forall (w :: GHC.Types.Levity) a (b :: TYPE w). (a -> b) -> a -> b As someone that's working on a book for beginners/intermediates and that mentions ($) early'ish, this is pretty disconcerting. Particularly as we're not going to explain Levity or TYPE. Is this intentional? My only ~/.ghci flag is fno-warn-type-defaults. Apologies if this is a mix-up on my part. --- Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.gl.scott at gmail.com Thu Feb 4 18:52:52 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Thu, 4 Feb 2016 13:52:52 -0500 Subject: New type of ($) operator in GHC 8.0 is problematic Message-ID: Hi Chris, The change to ($)'s type is indeed intentional. The short answer is that ($)'s type prior to GHC 8.0 was lying a little bit. If you defined something like this: unwrapInt :: Int -> Int# unwrapInt (I# i) = i You could write an expression like (unwrapInt $ 42), and it would typecheck. But that technically shouldn't be happening, since ($) :: (a -> b) -> a -> b, and we all know that polymorphic types have to live in kind *. But if you look at unwrapInt :: Int -> Int#, the type Int# certainly doesn't live in *. So why is this happening? The long answer is that prior to GHC 8.0, in the type signature ($) :: (a -> b) -> a -> b, b actually wasn't in kind *, but rather OpenKind. OpenKind is an awful hack that allows both lifted (kind *) and unlifted (kind #) types to inhabit it, which is why (unwrapInt $ 42) typechecks. To get rid of the hackiness of OpenKind, Richard Eisenberg extended the type system with levity polymorphism [1] to indicate in the type signature where these kind of scenarios are happening. So in the "new" type signature for ($): ($) :: forall (w :: Levity) a (b :: TYPE w). (a -> b) -> a -> b The type b can either live in kind * (which is now a synonym for TYPE 'Lifted) or kind # (which is a synonym for TYPE 'Unlifted), which is indicated by the fact that TYPE w is polymorphic in its levity type w. Truth be told, there aren't that many Haskell functions that actually levity polymorphic, since normally having an argument type that could live in either * or # would wreak havoc with the RTS (otherwise, how would it know if it's dealing with a pointer or a value on the stack?). But as it turns out, it's perfectly okay to have a levity polymorphic type in a non-argument position [2]. Indeed, in the few levity polymorphic functions that I can think of: ($) :: forall (w :: Levity) a (b :: TYPE w). (a -> b) -> a -> b error :: forall (v :: Levity) (a :: TYPE v). HasCallStack => [Char] -> a undefined :: forall (v :: Levity) (a :: TYPE v). HasCallStack => a The levity polymorphic type never appears directly to the left of an arrow. The downside of all this is, of course, that the type signature of ($) might look a lot scarier to beginners. I'm not sure how you'd want to deal with this, but for 99% of most use cases, it's okay to lie and state that ($) :: (a -> b) -> a -> b. You might have to include a disclaimer that if they type :t ($) into GHCi, they should be prepared for some extra information! Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds [2] https://ghc.haskell.org/trac/ghc/ticket/11473 From cma at bitemyapp.com Thu Feb 4 19:53:18 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Thu, 4 Feb 2016 13:53:18 -0600 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: References: Message-ID: My understanding was that the implicitly polymorphic levity, did (->) not change because it's a type constructor? Prelude> :info (->) data (->) a b -- Defined in ?GHC.Prim? Prelude> :k (->) (->) :: * -> * -> * Basically I'm asking why ($) changed and (->) did not when (->) had similar properties WRT * and #. Also does this encapsulate the implicit impredicativity of ($) for making runST $ work? I don't presently see how it would. Worry not about the book, we already hand-wave FTP effectively. One more type shouldn't change much. Thank you very much for answering, this has been very helpful already :) --- Chris On Thu, Feb 4, 2016 at 12:52 PM, Ryan Scott wrote: > Hi Chris, > > The change to ($)'s type is indeed intentional. The short answer is > that ($)'s type prior to GHC 8.0 was lying a little bit. If you > defined something like this: > > unwrapInt :: Int -> Int# > unwrapInt (I# i) = i > > You could write an expression like (unwrapInt $ 42), and it would > typecheck. But that technically shouldn't be happening, since ($) :: > (a -> b) -> a -> b, and we all know that polymorphic types have to > live in kind *. But if you look at unwrapInt :: Int -> Int#, the type > Int# certainly doesn't live in *. So why is this happening? > > The long answer is that prior to GHC 8.0, in the type signature ($) :: > (a -> b) -> a -> b, b actually wasn't in kind *, but rather OpenKind. > OpenKind is an awful hack that allows both lifted (kind *) and > unlifted (kind #) types to inhabit it, which is why (unwrapInt $ 42) > typechecks. To get rid of the hackiness of OpenKind, Richard Eisenberg > extended the type system with levity polymorphism [1] to indicate in > the type signature where these kind of scenarios are happening. > > So in the "new" type signature for ($): > > ($) :: forall (w :: Levity) a (b :: TYPE w). (a -> b) -> a -> b > > The type b can either live in kind * (which is now a synonym for TYPE > 'Lifted) or kind # (which is a synonym for TYPE 'Unlifted), which is > indicated by the fact that TYPE w is polymorphic in its levity type w. > > Truth be told, there aren't that many Haskell functions that actually > levity polymorphic, since normally having an argument type that could > live in either * or # would wreak havoc with the RTS (otherwise, how > would it know if it's dealing with a pointer or a value on the > stack?). But as it turns out, it's perfectly okay to have a levity > polymorphic type in a non-argument position [2]. Indeed, in the few > levity polymorphic functions that I can think of: > > ($) :: forall (w :: Levity) a (b :: TYPE w). (a -> b) -> a -> b > error :: forall (v :: Levity) (a :: TYPE v). HasCallStack => > [Char] -> a > undefined :: forall (v :: Levity) (a :: TYPE v). HasCallStack => a > > The levity polymorphic type never appears directly to the left of an arrow. > > The downside of all this is, of course, that the type signature of ($) > might look a lot scarier to beginners. I'm not sure how you'd want to > deal with this, but for 99% of most use cases, it's okay to lie and > state that ($) :: (a -> b) -> a -> b. You might have to include a > disclaimer that if they type :t ($) into GHCi, they should be prepared > for some extra information! > > Ryan S. > ----- > [1] https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds > [2] https://ghc.haskell.org/trac/ghc/ticket/11473 > _______________________________________________ > 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 cma at bitemyapp.com Thu Feb 4 19:55:25 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Thu, 4 Feb 2016 13:55:25 -0600 Subject: Guarantees for ST and IO shared in common? In-Reply-To: <53e30cd5bc40480faf01bda8fb857fce@DB4PR30MB030.064d.mgd.msft.net> References: <53e30cd5bc40480faf01bda8fb857fce@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Perfect, thank you very much Simon! I know you're busy so you taking the time to answer questions like this is a much appreciated gift. On Thu, Feb 4, 2016 at 6:11 AM, Simon Peyton Jones wrote: > that the mechanism for preventing things like reordering operations or > spurious sharing is shared in common between ST and IO via State# > > > > Yes. It?s pure data dependency, no more and no less. Operations in both ST > and IO take a State# token as input, and produce one as output. So of > course to get the input one, all preceding operations must be done first. > Simple! > > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Christopher > Allen > *Sent:* 03 February 2016 23:30 > *To:* ghc-devs at haskell.org > *Subject:* Guarantees for ST and IO shared in common? > > > > Underlying ST is: GHC.Prim.State# s -> (# GHC.Prim.State# s, a #) > > > > Underlying IO is: GHC.Prim.State# GHC.Prim.RealWorld > > -> (# GHC.Prim.State# GHC.Prim.RealWorld, a #) > > > > Based on the (very helpful!) conversation I had on the #ghc IRC channel, > it seems to me that the mechanism for preventing things like reordering > operations or spurious sharing is shared in common between ST and IO via > State#. Is this accurate? I believe the exception is how RealWorld is used > w/ IO but we can put that off for this question. > > > > If anyone could confirm this understanding that would be helpful. If > anyone could point out exceptions to this notion, I'd very much appreciate > that as well. > > > > > > Thanks again for everyone's time. > > > > -- > > Chris Allen > > Currently working on http://haskellbook.com > > -- Chris Allen Currently working on http://haskellbook.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Thu Feb 4 20:26:02 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 04 Feb 2016 21:26:02 +0100 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: References: Message-ID: <878u30b4th.fsf@smart-cactus.org> Christopher Allen writes: > My understanding was that the implicitly polymorphic levity, did (->) not > change because it's a type constructor? > > Prelude> :info (->) > data (->) a b -- Defined in ?GHC.Prim? > Prelude> :k (->) > (->) :: * -> * -> * > > Basically I'm asking why ($) changed and (->) did not when (->) had similar > properties WRT * and #. > Yes, there is a bit of an inconsistency here. As far as I understand there is still a bit of magic around (->), which allows it to be more polymorphic than it appears. There's a bit of evidence of this magic here [1]. Cheers, - Ben [1] https://github.com/ghc/ghc/blob/84b0ebedd09fcfbda8efd7576dce9f52a2b6e6ca/compiler/prelude/TysPrim.hs#L262 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ryan.gl.scott at gmail.com Thu Feb 4 20:27:07 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Thu, 4 Feb 2016 15:27:07 -0500 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: References: Message-ID: > My understanding was that the implicitly polymorphic levity, did (->) not change because it's a type constructor? The kind of (->) as GHCi reports it is technically correct. As a kind constructor, (->) has precisely the kind * -> * -> *. What's special about (->) is that when you have a saturated application of it, it takes on a levity-polymorphic kind. For example, this: :k (->) Int# Int# would yield a kind error, but :k Int# -> Int# is okay. Now, if you want an explanation as to WHY that's the case, I don't think I could give one, as I simply got this information from [1] (see the fourth bullet point, for OpenKind). Perhaps SPJ or Richard Eisenberg could give a little insight here. > Also does this encapsulate the implicit impredicativity of ($) for making runST $ work? I don't presently see how it would. You're right, the impredicativity hack is a completely different thing. So while you won't be able to define your own ($) and be able to (runST $ do ...), you can at least define your own ($) and have it work with unlifted return types. :) Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds On Thu, Feb 4, 2016 at 2:53 PM, Christopher Allen wrote: > My understanding was that the implicitly polymorphic levity, did (->) not > change because it's a type constructor? > > Prelude> :info (->) > data (->) a b -- Defined in ?GHC.Prim? > Prelude> :k (->) > (->) :: * -> * -> * > > Basically I'm asking why ($) changed and (->) did not when (->) had similar > properties WRT * and #. > > Also does this encapsulate the implicit impredicativity of ($) for making > runST $ work? I don't presently see how it would. > > Worry not about the book, we already hand-wave FTP effectively. One more > type shouldn't change much. > > Thank you very much for answering, this has been very helpful already :) > > --- Chris > > > On Thu, Feb 4, 2016 at 12:52 PM, Ryan Scott wrote: >> >> Hi Chris, >> >> The change to ($)'s type is indeed intentional. The short answer is >> that ($)'s type prior to GHC 8.0 was lying a little bit. If you >> defined something like this: >> >> unwrapInt :: Int -> Int# >> unwrapInt (I# i) = i >> >> You could write an expression like (unwrapInt $ 42), and it would >> typecheck. But that technically shouldn't be happening, since ($) :: >> (a -> b) -> a -> b, and we all know that polymorphic types have to >> live in kind *. But if you look at unwrapInt :: Int -> Int#, the type >> Int# certainly doesn't live in *. So why is this happening? >> >> The long answer is that prior to GHC 8.0, in the type signature ($) :: >> (a -> b) -> a -> b, b actually wasn't in kind *, but rather OpenKind. >> OpenKind is an awful hack that allows both lifted (kind *) and >> unlifted (kind #) types to inhabit it, which is why (unwrapInt $ 42) >> typechecks. To get rid of the hackiness of OpenKind, Richard Eisenberg >> extended the type system with levity polymorphism [1] to indicate in >> the type signature where these kind of scenarios are happening. >> >> So in the "new" type signature for ($): >> >> ($) :: forall (w :: Levity) a (b :: TYPE w). (a -> b) -> a -> b >> >> The type b can either live in kind * (which is now a synonym for TYPE >> 'Lifted) or kind # (which is a synonym for TYPE 'Unlifted), which is >> indicated by the fact that TYPE w is polymorphic in its levity type w. >> >> Truth be told, there aren't that many Haskell functions that actually >> levity polymorphic, since normally having an argument type that could >> live in either * or # would wreak havoc with the RTS (otherwise, how >> would it know if it's dealing with a pointer or a value on the >> stack?). But as it turns out, it's perfectly okay to have a levity >> polymorphic type in a non-argument position [2]. Indeed, in the few >> levity polymorphic functions that I can think of: >> >> ($) :: forall (w :: Levity) a (b :: TYPE w). (a -> b) -> a -> b >> error :: forall (v :: Levity) (a :: TYPE v). HasCallStack => >> [Char] -> a >> undefined :: forall (v :: Levity) (a :: TYPE v). HasCallStack => a >> >> The levity polymorphic type never appears directly to the left of an >> arrow. >> >> The downside of all this is, of course, that the type signature of ($) >> might look a lot scarier to beginners. I'm not sure how you'd want to >> deal with this, but for 99% of most use cases, it's okay to lie and >> state that ($) :: (a -> b) -> a -> b. You might have to include a >> disclaimer that if they type :t ($) into GHCi, they should be prepared >> for some extra information! >> >> Ryan S. >> ----- >> [1] https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds >> [2] https://ghc.haskell.org/trac/ghc/ticket/11473 >> _______________________________________________ >> 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 From eir at cis.upenn.edu Thu Feb 4 21:15:37 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Thu, 4 Feb 2016 16:15:37 -0500 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: References: Message-ID: I agree with everything that's been said in this thread, including the unstated "that type for ($) is sure ugly". Currently, saturated (a -> b) is like a language construct, and it has its own typing rule, independent of the type of the type constructor (->). But reading the comment that Ben linked to, I think that comment is out of date. Now that we have levity polymorphism, we can probably to the Right Thing and make the kind of (->) more flexible. Richard On Feb 4, 2016, at 3:27 PM, Ryan Scott wrote: >> My understanding was that the implicitly polymorphic levity, did (->) not change because it's a type constructor? > > The kind of (->) as GHCi reports it is technically correct. As a kind > constructor, (->) has precisely the kind * -> * -> *. What's special > about (->) is that when you have a saturated application of it, it > takes on a levity-polymorphic kind. For example, this: > > :k (->) Int# Int# > > would yield a kind error, but > > :k Int# -> Int# > > is okay. Now, if you want an explanation as to WHY that's the case, I > don't think I could give one, as I simply got this information from > [1] (see the fourth bullet point, for OpenKind). Perhaps SPJ or > Richard Eisenberg could give a little insight here. > >> Also does this encapsulate the implicit impredicativity of ($) for making runST $ work? I don't presently see how it would. > > You're right, the impredicativity hack is a completely different > thing. So while you won't be able to define your own ($) and be able > to (runST $ do ...), you can at least define your own ($) and have it > work with unlifted return types. :) > > Ryan S. > ----- > [1] https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds > > On Thu, Feb 4, 2016 at 2:53 PM, Christopher Allen wrote: >> My understanding was that the implicitly polymorphic levity, did (->) not >> change because it's a type constructor? >> >> Prelude> :info (->) >> data (->) a b -- Defined in ?GHC.Prim? >> Prelude> :k (->) >> (->) :: * -> * -> * >> >> Basically I'm asking why ($) changed and (->) did not when (->) had similar >> properties WRT * and #. >> >> Also does this encapsulate the implicit impredicativity of ($) for making >> runST $ work? I don't presently see how it would. >> >> Worry not about the book, we already hand-wave FTP effectively. One more >> type shouldn't change much. >> >> Thank you very much for answering, this has been very helpful already :) >> >> --- Chris >> >> >> On Thu, Feb 4, 2016 at 12:52 PM, Ryan Scott wrote: >>> >>> Hi Chris, >>> >>> The change to ($)'s type is indeed intentional. The short answer is >>> that ($)'s type prior to GHC 8.0 was lying a little bit. If you >>> defined something like this: >>> >>> unwrapInt :: Int -> Int# >>> unwrapInt (I# i) = i >>> >>> You could write an expression like (unwrapInt $ 42), and it would >>> typecheck. But that technically shouldn't be happening, since ($) :: >>> (a -> b) -> a -> b, and we all know that polymorphic types have to >>> live in kind *. But if you look at unwrapInt :: Int -> Int#, the type >>> Int# certainly doesn't live in *. So why is this happening? >>> >>> The long answer is that prior to GHC 8.0, in the type signature ($) :: >>> (a -> b) -> a -> b, b actually wasn't in kind *, but rather OpenKind. >>> OpenKind is an awful hack that allows both lifted (kind *) and >>> unlifted (kind #) types to inhabit it, which is why (unwrapInt $ 42) >>> typechecks. To get rid of the hackiness of OpenKind, Richard Eisenberg >>> extended the type system with levity polymorphism [1] to indicate in >>> the type signature where these kind of scenarios are happening. >>> >>> So in the "new" type signature for ($): >>> >>> ($) :: forall (w :: Levity) a (b :: TYPE w). (a -> b) -> a -> b >>> >>> The type b can either live in kind * (which is now a synonym for TYPE >>> 'Lifted) or kind # (which is a synonym for TYPE 'Unlifted), which is >>> indicated by the fact that TYPE w is polymorphic in its levity type w. >>> >>> Truth be told, there aren't that many Haskell functions that actually >>> levity polymorphic, since normally having an argument type that could >>> live in either * or # would wreak havoc with the RTS (otherwise, how >>> would it know if it's dealing with a pointer or a value on the >>> stack?). But as it turns out, it's perfectly okay to have a levity >>> polymorphic type in a non-argument position [2]. Indeed, in the few >>> levity polymorphic functions that I can think of: >>> >>> ($) :: forall (w :: Levity) a (b :: TYPE w). (a -> b) -> a -> b >>> error :: forall (v :: Levity) (a :: TYPE v). HasCallStack => >>> [Char] -> a >>> undefined :: forall (v :: Levity) (a :: TYPE v). HasCallStack => a >>> >>> The levity polymorphic type never appears directly to the left of an >>> arrow. >>> >>> The downside of all this is, of course, that the type signature of ($) >>> might look a lot scarier to beginners. I'm not sure how you'd want to >>> deal with this, but for 99% of most use cases, it's okay to lie and >>> state that ($) :: (a -> b) -> a -> b. You might have to include a >>> disclaimer that if they type :t ($) into GHCi, they should be prepared >>> for some extra information! >>> >>> Ryan S. >>> ----- >>> [1] https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds >>> [2] https://ghc.haskell.org/trac/ghc/ticket/11473 >>> _______________________________________________ >>> 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 > _______________________________________________ > 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 Thu Feb 4 22:56:56 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Thu, 4 Feb 2016 17:56:56 -0500 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: References: Message-ID: Out of curiosity, what should the kind of (->) be? Both the argument and result kind of (->) can be either * or #, but we can't make the argument kind levity polymorphic due to [1], right? How would you encode that in a kind signature? Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/11473 On Thu, Feb 4, 2016 at 4:15 PM, Richard Eisenberg wrote: > I agree with everything that's been said in this thread, including the unstated "that type for ($) is sure ugly". > > Currently, saturated (a -> b) is like a language construct, and it has its own typing rule, independent of the type of the type constructor (->). But reading the comment that Ben linked to, I think that comment is out of date. Now that we have levity polymorphism, we can probably to the Right Thing and make the kind of (->) more flexible. > > Richard > > On Feb 4, 2016, at 3:27 PM, Ryan Scott wrote: > >>> My understanding was that the implicitly polymorphic levity, did (->) not change because it's a type constructor? >> >> The kind of (->) as GHCi reports it is technically correct. As a kind >> constructor, (->) has precisely the kind * -> * -> *. What's special >> about (->) is that when you have a saturated application of it, it >> takes on a levity-polymorphic kind. For example, this: >> >> :k (->) Int# Int# >> >> would yield a kind error, but >> >> :k Int# -> Int# >> >> is okay. Now, if you want an explanation as to WHY that's the case, I >> don't think I could give one, as I simply got this information from >> [1] (see the fourth bullet point, for OpenKind). Perhaps SPJ or >> Richard Eisenberg could give a little insight here. >> >>> Also does this encapsulate the implicit impredicativity of ($) for making runST $ work? I don't presently see how it would. >> >> You're right, the impredicativity hack is a completely different >> thing. So while you won't be able to define your own ($) and be able >> to (runST $ do ...), you can at least define your own ($) and have it >> work with unlifted return types. :) >> >> Ryan S. >> ----- >> [1] https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds >> >> On Thu, Feb 4, 2016 at 2:53 PM, Christopher Allen wrote: >>> My understanding was that the implicitly polymorphic levity, did (->) not >>> change because it's a type constructor? >>> >>> Prelude> :info (->) >>> data (->) a b -- Defined in ?GHC.Prim? >>> Prelude> :k (->) >>> (->) :: * -> * -> * >>> >>> Basically I'm asking why ($) changed and (->) did not when (->) had similar >>> properties WRT * and #. >>> >>> Also does this encapsulate the implicit impredicativity of ($) for making >>> runST $ work? I don't presently see how it would. >>> >>> Worry not about the book, we already hand-wave FTP effectively. One more >>> type shouldn't change much. >>> >>> Thank you very much for answering, this has been very helpful already :) >>> >>> --- Chris >>> >>> >>> On Thu, Feb 4, 2016 at 12:52 PM, Ryan Scott wrote: >>>> >>>> Hi Chris, >>>> >>>> The change to ($)'s type is indeed intentional. The short answer is >>>> that ($)'s type prior to GHC 8.0 was lying a little bit. If you >>>> defined something like this: >>>> >>>> unwrapInt :: Int -> Int# >>>> unwrapInt (I# i) = i >>>> >>>> You could write an expression like (unwrapInt $ 42), and it would >>>> typecheck. But that technically shouldn't be happening, since ($) :: >>>> (a -> b) -> a -> b, and we all know that polymorphic types have to >>>> live in kind *. But if you look at unwrapInt :: Int -> Int#, the type >>>> Int# certainly doesn't live in *. So why is this happening? >>>> >>>> The long answer is that prior to GHC 8.0, in the type signature ($) :: >>>> (a -> b) -> a -> b, b actually wasn't in kind *, but rather OpenKind. >>>> OpenKind is an awful hack that allows both lifted (kind *) and >>>> unlifted (kind #) types to inhabit it, which is why (unwrapInt $ 42) >>>> typechecks. To get rid of the hackiness of OpenKind, Richard Eisenberg >>>> extended the type system with levity polymorphism [1] to indicate in >>>> the type signature where these kind of scenarios are happening. >>>> >>>> So in the "new" type signature for ($): >>>> >>>> ($) :: forall (w :: Levity) a (b :: TYPE w). (a -> b) -> a -> b >>>> >>>> The type b can either live in kind * (which is now a synonym for TYPE >>>> 'Lifted) or kind # (which is a synonym for TYPE 'Unlifted), which is >>>> indicated by the fact that TYPE w is polymorphic in its levity type w. >>>> >>>> Truth be told, there aren't that many Haskell functions that actually >>>> levity polymorphic, since normally having an argument type that could >>>> live in either * or # would wreak havoc with the RTS (otherwise, how >>>> would it know if it's dealing with a pointer or a value on the >>>> stack?). But as it turns out, it's perfectly okay to have a levity >>>> polymorphic type in a non-argument position [2]. Indeed, in the few >>>> levity polymorphic functions that I can think of: >>>> >>>> ($) :: forall (w :: Levity) a (b :: TYPE w). (a -> b) -> a -> b >>>> error :: forall (v :: Levity) (a :: TYPE v). HasCallStack => >>>> [Char] -> a >>>> undefined :: forall (v :: Levity) (a :: TYPE v). HasCallStack => a >>>> >>>> The levity polymorphic type never appears directly to the left of an >>>> arrow. >>>> >>>> The downside of all this is, of course, that the type signature of ($) >>>> might look a lot scarier to beginners. I'm not sure how you'd want to >>>> deal with this, but for 99% of most use cases, it's okay to lie and >>>> state that ($) :: (a -> b) -> a -> b. You might have to include a >>>> disclaimer that if they type :t ($) into GHCi, they should be prepared >>>> for some extra information! >>>> >>>> Ryan S. >>>> ----- >>>> [1] https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds >>>> [2] https://ghc.haskell.org/trac/ghc/ticket/11473 >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > From cma at bitemyapp.com Thu Feb 4 22:57:33 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Thu, 4 Feb 2016 16:57:33 -0600 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: References: Message-ID: > make the kind of (->) more flexible. Can that wait until 8.2 so we don't have to edit the book as much in preparation for 8.0? :P On Thu, Feb 4, 2016 at 3:15 PM, Richard Eisenberg wrote: > I agree with everything that's been said in this thread, including the > unstated "that type for ($) is sure ugly". > > Currently, saturated (a -> b) is like a language construct, and it has its > own typing rule, independent of the type of the type constructor (->). But > reading the comment that Ben linked to, I think that comment is out of > date. Now that we have levity polymorphism, we can probably to the Right > Thing and make the kind of (->) more flexible. > > Richard > > On Feb 4, 2016, at 3:27 PM, Ryan Scott wrote: > > >> My understanding was that the implicitly polymorphic levity, did (->) > not change because it's a type constructor? > > > > The kind of (->) as GHCi reports it is technically correct. As a kind > > constructor, (->) has precisely the kind * -> * -> *. What's special > > about (->) is that when you have a saturated application of it, it > > takes on a levity-polymorphic kind. For example, this: > > > > :k (->) Int# Int# > > > > would yield a kind error, but > > > > :k Int# -> Int# > > > > is okay. Now, if you want an explanation as to WHY that's the case, I > > don't think I could give one, as I simply got this information from > > [1] (see the fourth bullet point, for OpenKind). Perhaps SPJ or > > Richard Eisenberg could give a little insight here. > > > >> Also does this encapsulate the implicit impredicativity of ($) for > making runST $ work? I don't presently see how it would. > > > > You're right, the impredicativity hack is a completely different > > thing. So while you won't be able to define your own ($) and be able > > to (runST $ do ...), you can at least define your own ($) and have it > > work with unlifted return types. :) > > > > Ryan S. > > ----- > > [1] https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds > > > > On Thu, Feb 4, 2016 at 2:53 PM, Christopher Allen > wrote: > >> My understanding was that the implicitly polymorphic levity, did (->) > not > >> change because it's a type constructor? > >> > >> Prelude> :info (->) > >> data (->) a b -- Defined in ?GHC.Prim? > >> Prelude> :k (->) > >> (->) :: * -> * -> * > >> > >> Basically I'm asking why ($) changed and (->) did not when (->) had > similar > >> properties WRT * and #. > >> > >> Also does this encapsulate the implicit impredicativity of ($) for > making > >> runST $ work? I don't presently see how it would. > >> > >> Worry not about the book, we already hand-wave FTP effectively. One more > >> type shouldn't change much. > >> > >> Thank you very much for answering, this has been very helpful already :) > >> > >> --- Chris > >> > >> > >> On Thu, Feb 4, 2016 at 12:52 PM, Ryan Scott > wrote: > >>> > >>> Hi Chris, > >>> > >>> The change to ($)'s type is indeed intentional. The short answer is > >>> that ($)'s type prior to GHC 8.0 was lying a little bit. If you > >>> defined something like this: > >>> > >>> unwrapInt :: Int -> Int# > >>> unwrapInt (I# i) = i > >>> > >>> You could write an expression like (unwrapInt $ 42), and it would > >>> typecheck. But that technically shouldn't be happening, since ($) :: > >>> (a -> b) -> a -> b, and we all know that polymorphic types have to > >>> live in kind *. But if you look at unwrapInt :: Int -> Int#, the type > >>> Int# certainly doesn't live in *. So why is this happening? > >>> > >>> The long answer is that prior to GHC 8.0, in the type signature ($) :: > >>> (a -> b) -> a -> b, b actually wasn't in kind *, but rather OpenKind. > >>> OpenKind is an awful hack that allows both lifted (kind *) and > >>> unlifted (kind #) types to inhabit it, which is why (unwrapInt $ 42) > >>> typechecks. To get rid of the hackiness of OpenKind, Richard Eisenberg > >>> extended the type system with levity polymorphism [1] to indicate in > >>> the type signature where these kind of scenarios are happening. > >>> > >>> So in the "new" type signature for ($): > >>> > >>> ($) :: forall (w :: Levity) a (b :: TYPE w). (a -> b) -> a -> b > >>> > >>> The type b can either live in kind * (which is now a synonym for TYPE > >>> 'Lifted) or kind # (which is a synonym for TYPE 'Unlifted), which is > >>> indicated by the fact that TYPE w is polymorphic in its levity type w. > >>> > >>> Truth be told, there aren't that many Haskell functions that actually > >>> levity polymorphic, since normally having an argument type that could > >>> live in either * or # would wreak havoc with the RTS (otherwise, how > >>> would it know if it's dealing with a pointer or a value on the > >>> stack?). But as it turns out, it's perfectly okay to have a levity > >>> polymorphic type in a non-argument position [2]. Indeed, in the few > >>> levity polymorphic functions that I can think of: > >>> > >>> ($) :: forall (w :: Levity) a (b :: TYPE w). (a -> b) -> a > -> b > >>> error :: forall (v :: Levity) (a :: TYPE v). HasCallStack => > >>> [Char] -> a > >>> undefined :: forall (v :: Levity) (a :: TYPE v). HasCallStack => a > >>> > >>> The levity polymorphic type never appears directly to the left of an > >>> arrow. > >>> > >>> The downside of all this is, of course, that the type signature of ($) > >>> might look a lot scarier to beginners. I'm not sure how you'd want to > >>> deal with this, but for 99% of most use cases, it's okay to lie and > >>> state that ($) :: (a -> b) -> a -> b. You might have to include a > >>> disclaimer that if they type :t ($) into GHCi, they should be prepared > >>> for some extra information! > >>> > >>> Ryan S. > >>> ----- > >>> [1] https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds > >>> [2] https://ghc.haskell.org/trac/ghc/ticket/11473 > >>> _______________________________________________ > >>> 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 > > _______________________________________________ > > 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 chak at justtesting.org Thu Feb 4 23:02:36 2016 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Fri, 5 Feb 2016 10:02:36 +1100 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: References: Message-ID: <0210F72D-CCF3-452A-BAD4-15796F288FD9@justtesting.org> To be honest, I think, it is quite problematic if an obscure and untested language extension (sorry, but that?s what it is right now) bleeds through into supposedly simple standard functionality. The beauty of most of GHC?s language extensions is that you can ignore them until you need them. Has this ever been discussed more widely? I expect that every single person teaching Haskell is going to be unhappy about it. Manuel > Richard Eisenberg : > > I agree with everything that's been said in this thread, including the unstated "that type for ($) is sure ugly". > > Currently, saturated (a -> b) is like a language construct, and it has its own typing rule, independent of the type of the type constructor (->). But reading the comment that Ben linked to, I think that comment is out of date. Now that we have levity polymorphism, we can probably to the Right Thing and make the kind of (->) more flexible. > > Richard > > On Feb 4, 2016, at 3:27 PM, Ryan Scott wrote: > >>> My understanding was that the implicitly polymorphic levity, did (->) not change because it's a type constructor? >> >> The kind of (->) as GHCi reports it is technically correct. As a kind >> constructor, (->) has precisely the kind * -> * -> *. What's special >> about (->) is that when you have a saturated application of it, it >> takes on a levity-polymorphic kind. For example, this: >> >> :k (->) Int# Int# >> >> would yield a kind error, but >> >> :k Int# -> Int# >> >> is okay. Now, if you want an explanation as to WHY that's the case, I >> don't think I could give one, as I simply got this information from >> [1] (see the fourth bullet point, for OpenKind). Perhaps SPJ or >> Richard Eisenberg could give a little insight here. >> >>> Also does this encapsulate the implicit impredicativity of ($) for making runST $ work? I don't presently see how it would. >> >> You're right, the impredicativity hack is a completely different >> thing. So while you won't be able to define your own ($) and be able >> to (runST $ do ...), you can at least define your own ($) and have it >> work with unlifted return types. :) >> >> Ryan S. >> ----- >> [1] https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds >> >> On Thu, Feb 4, 2016 at 2:53 PM, Christopher Allen wrote: >>> My understanding was that the implicitly polymorphic levity, did (->) not >>> change because it's a type constructor? >>> >>> Prelude> :info (->) >>> data (->) a b -- Defined in ?GHC.Prim? >>> Prelude> :k (->) >>> (->) :: * -> * -> * >>> >>> Basically I'm asking why ($) changed and (->) did not when (->) had similar >>> properties WRT * and #. >>> >>> Also does this encapsulate the implicit impredicativity of ($) for making >>> runST $ work? I don't presently see how it would. >>> >>> Worry not about the book, we already hand-wave FTP effectively. One more >>> type shouldn't change much. >>> >>> Thank you very much for answering, this has been very helpful already :) >>> >>> --- Chris >>> >>> >>> On Thu, Feb 4, 2016 at 12:52 PM, Ryan Scott wrote: >>>> >>>> Hi Chris, >>>> >>>> The change to ($)'s type is indeed intentional. The short answer is >>>> that ($)'s type prior to GHC 8.0 was lying a little bit. If you >>>> defined something like this: >>>> >>>> unwrapInt :: Int -> Int# >>>> unwrapInt (I# i) = i >>>> >>>> You could write an expression like (unwrapInt $ 42), and it would >>>> typecheck. But that technically shouldn't be happening, since ($) :: >>>> (a -> b) -> a -> b, and we all know that polymorphic types have to >>>> live in kind *. But if you look at unwrapInt :: Int -> Int#, the type >>>> Int# certainly doesn't live in *. So why is this happening? >>>> >>>> The long answer is that prior to GHC 8.0, in the type signature ($) :: >>>> (a -> b) -> a -> b, b actually wasn't in kind *, but rather OpenKind. >>>> OpenKind is an awful hack that allows both lifted (kind *) and >>>> unlifted (kind #) types to inhabit it, which is why (unwrapInt $ 42) >>>> typechecks. To get rid of the hackiness of OpenKind, Richard Eisenberg >>>> extended the type system with levity polymorphism [1] to indicate in >>>> the type signature where these kind of scenarios are happening. >>>> >>>> So in the "new" type signature for ($): >>>> >>>> ($) :: forall (w :: Levity) a (b :: TYPE w). (a -> b) -> a -> b >>>> >>>> The type b can either live in kind * (which is now a synonym for TYPE >>>> 'Lifted) or kind # (which is a synonym for TYPE 'Unlifted), which is >>>> indicated by the fact that TYPE w is polymorphic in its levity type w. >>>> >>>> Truth be told, there aren't that many Haskell functions that actually >>>> levity polymorphic, since normally having an argument type that could >>>> live in either * or # would wreak havoc with the RTS (otherwise, how >>>> would it know if it's dealing with a pointer or a value on the >>>> stack?). But as it turns out, it's perfectly okay to have a levity >>>> polymorphic type in a non-argument position [2]. Indeed, in the few >>>> levity polymorphic functions that I can think of: >>>> >>>> ($) :: forall (w :: Levity) a (b :: TYPE w). (a -> b) -> a -> b >>>> error :: forall (v :: Levity) (a :: TYPE v). HasCallStack => >>>> [Char] -> a >>>> undefined :: forall (v :: Levity) (a :: TYPE v). HasCallStack => a >>>> >>>> The levity polymorphic type never appears directly to the left of an >>>> arrow. >>>> >>>> The downside of all this is, of course, that the type signature of ($) >>>> might look a lot scarier to beginners. I'm not sure how you'd want to >>>> deal with this, but for 99% of most use cases, it's okay to lie and >>>> state that ($) :: (a -> b) -> a -> b. You might have to include a >>>> disclaimer that if they type :t ($) into GHCi, they should be prepared >>>> for some extra information! >>>> >>>> Ryan S. >>>> ----- >>>> [1] https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds >>>> [2] https://ghc.haskell.org/trac/ghc/ticket/11473 >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> 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 cma at bitemyapp.com Thu Feb 4 23:20:34 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Thu, 4 Feb 2016 17:20:34 -0600 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: <0210F72D-CCF3-452A-BAD4-15796F288FD9@justtesting.org> References: <0210F72D-CCF3-452A-BAD4-15796F288FD9@justtesting.org> Message-ID: This seems worse than FTP IMO. It's considerably noisier, considerably rarer a concern for Haskell programmers, and is wayyyy beyond the scope of most learning resources. Is there a reason this isn't behind a pragma? On Thu, Feb 4, 2016 at 5:02 PM, Manuel M T Chakravarty wrote: > To be honest, I think, it is quite problematic if an obscure and untested > language extension (sorry, but that?s what it is right now) bleeds through > into supposedly simple standard functionality. The beauty of most of GHC?s > language extensions is that you can ignore them until you need them. > > Has this ever been discussed more widely? I expect that every single > person teaching Haskell is going to be unhappy about it. > > Manuel > > > > Richard Eisenberg : > > > > I agree with everything that's been said in this thread, including the > unstated "that type for ($) is sure ugly". > > > > Currently, saturated (a -> b) is like a language construct, and it has > its own typing rule, independent of the type of the type constructor (->). > But reading the comment that Ben linked to, I think that comment is out of > date. Now that we have levity polymorphism, we can probably to the Right > Thing and make the kind of (->) more flexible. > > > > Richard > > > > On Feb 4, 2016, at 3:27 PM, Ryan Scott wrote: > > > >>> My understanding was that the implicitly polymorphic levity, did (->) > not change because it's a type constructor? > >> > >> The kind of (->) as GHCi reports it is technically correct. As a kind > >> constructor, (->) has precisely the kind * -> * -> *. What's special > >> about (->) is that when you have a saturated application of it, it > >> takes on a levity-polymorphic kind. For example, this: > >> > >> :k (->) Int# Int# > >> > >> would yield a kind error, but > >> > >> :k Int# -> Int# > >> > >> is okay. Now, if you want an explanation as to WHY that's the case, I > >> don't think I could give one, as I simply got this information from > >> [1] (see the fourth bullet point, for OpenKind). Perhaps SPJ or > >> Richard Eisenberg could give a little insight here. > >> > >>> Also does this encapsulate the implicit impredicativity of ($) for > making runST $ work? I don't presently see how it would. > >> > >> You're right, the impredicativity hack is a completely different > >> thing. So while you won't be able to define your own ($) and be able > >> to (runST $ do ...), you can at least define your own ($) and have it > >> work with unlifted return types. :) > >> > >> Ryan S. > >> ----- > >> [1] https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds > >> > >> On Thu, Feb 4, 2016 at 2:53 PM, Christopher Allen > wrote: > >>> My understanding was that the implicitly polymorphic levity, did (->) > not > >>> change because it's a type constructor? > >>> > >>> Prelude> :info (->) > >>> data (->) a b -- Defined in ?GHC.Prim? > >>> Prelude> :k (->) > >>> (->) :: * -> * -> * > >>> > >>> Basically I'm asking why ($) changed and (->) did not when (->) had > similar > >>> properties WRT * and #. > >>> > >>> Also does this encapsulate the implicit impredicativity of ($) for > making > >>> runST $ work? I don't presently see how it would. > >>> > >>> Worry not about the book, we already hand-wave FTP effectively. One > more > >>> type shouldn't change much. > >>> > >>> Thank you very much for answering, this has been very helpful already > :) > >>> > >>> --- Chris > >>> > >>> > >>> On Thu, Feb 4, 2016 at 12:52 PM, Ryan Scott > wrote: > >>>> > >>>> Hi Chris, > >>>> > >>>> The change to ($)'s type is indeed intentional. The short answer is > >>>> that ($)'s type prior to GHC 8.0 was lying a little bit. If you > >>>> defined something like this: > >>>> > >>>> unwrapInt :: Int -> Int# > >>>> unwrapInt (I# i) = i > >>>> > >>>> You could write an expression like (unwrapInt $ 42), and it would > >>>> typecheck. But that technically shouldn't be happening, since ($) :: > >>>> (a -> b) -> a -> b, and we all know that polymorphic types have to > >>>> live in kind *. But if you look at unwrapInt :: Int -> Int#, the type > >>>> Int# certainly doesn't live in *. So why is this happening? > >>>> > >>>> The long answer is that prior to GHC 8.0, in the type signature ($) :: > >>>> (a -> b) -> a -> b, b actually wasn't in kind *, but rather OpenKind. > >>>> OpenKind is an awful hack that allows both lifted (kind *) and > >>>> unlifted (kind #) types to inhabit it, which is why (unwrapInt $ 42) > >>>> typechecks. To get rid of the hackiness of OpenKind, Richard Eisenberg > >>>> extended the type system with levity polymorphism [1] to indicate in > >>>> the type signature where these kind of scenarios are happening. > >>>> > >>>> So in the "new" type signature for ($): > >>>> > >>>> ($) :: forall (w :: Levity) a (b :: TYPE w). (a -> b) -> a -> b > >>>> > >>>> The type b can either live in kind * (which is now a synonym for TYPE > >>>> 'Lifted) or kind # (which is a synonym for TYPE 'Unlifted), which is > >>>> indicated by the fact that TYPE w is polymorphic in its levity type w. > >>>> > >>>> Truth be told, there aren't that many Haskell functions that actually > >>>> levity polymorphic, since normally having an argument type that could > >>>> live in either * or # would wreak havoc with the RTS (otherwise, how > >>>> would it know if it's dealing with a pointer or a value on the > >>>> stack?). But as it turns out, it's perfectly okay to have a levity > >>>> polymorphic type in a non-argument position [2]. Indeed, in the few > >>>> levity polymorphic functions that I can think of: > >>>> > >>>> ($) :: forall (w :: Levity) a (b :: TYPE w). (a -> b) -> a > -> b > >>>> error :: forall (v :: Levity) (a :: TYPE v). HasCallStack => > >>>> [Char] -> a > >>>> undefined :: forall (v :: Levity) (a :: TYPE v). HasCallStack => a > >>>> > >>>> The levity polymorphic type never appears directly to the left of an > >>>> arrow. > >>>> > >>>> The downside of all this is, of course, that the type signature of ($) > >>>> might look a lot scarier to beginners. I'm not sure how you'd want to > >>>> deal with this, but for 99% of most use cases, it's okay to lie and > >>>> state that ($) :: (a -> b) -> a -> b. You might have to include a > >>>> disclaimer that if they type :t ($) into GHCi, they should be prepared > >>>> for some extra information! > >>>> > >>>> Ryan S. > >>>> ----- > >>>> [1] https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds > >>>> [2] https://ghc.haskell.org/trac/ghc/ticket/11473 > >>>> _______________________________________________ > >>>> 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 > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >> > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Chris Allen Currently working on http://haskellbook.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Thu Feb 4 23:31:35 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Thu, 04 Feb 2016 15:31:35 -0800 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: References: <0210F72D-CCF3-452A-BAD4-15796F288FD9@justtesting.org> Message-ID: <1454628457-sup-7751@sabre> I'm not really sure how you would change the type of 'id' based on a language pragma. How do people feel about a cosmetic fix, where we introduce a new pragma, {-# LANGUAGE ShowLevity #-} which controls the display of levity arguments/TYPE. It's off by default but gets turned on by some extensions like MagicHash (i.e. we only show levity if you have enabled extensions where the distinction matters). Edward Excerpts from Christopher Allen's message of 2016-02-04 15:20:34 -0800: > This seems worse than FTP IMO. It's considerably noisier, considerably > rarer a concern for Haskell programmers, and is wayyyy beyond the scope of > most learning resources. > > Is there a reason this isn't behind a pragma? > > On Thu, Feb 4, 2016 at 5:02 PM, Manuel M T Chakravarty > wrote: > > > To be honest, I think, it is quite problematic if an obscure and untested > > language extension (sorry, but that?s what it is right now) bleeds through > > into supposedly simple standard functionality. The beauty of most of GHC?s > > language extensions is that you can ignore them until you need them. > > > > Has this ever been discussed more widely? I expect that every single > > person teaching Haskell is going to be unhappy about it. > > > > Manuel > > > > > > > Richard Eisenberg : > > > > > > I agree with everything that's been said in this thread, including the > > unstated "that type for ($) is sure ugly". > > > > > > Currently, saturated (a -> b) is like a language construct, and it has > > its own typing rule, independent of the type of the type constructor (->). > > But reading the comment that Ben linked to, I think that comment is out of > > date. Now that we have levity polymorphism, we can probably to the Right > > Thing and make the kind of (->) more flexible. > > > > > > Richard > > > > > > On Feb 4, 2016, at 3:27 PM, Ryan Scott wrote: > > > > > >>> My understanding was that the implicitly polymorphic levity, did (->) > > not change because it's a type constructor? > > >> > > >> The kind of (->) as GHCi reports it is technically correct. As a kind > > >> constructor, (->) has precisely the kind * -> * -> *. What's special > > >> about (->) is that when you have a saturated application of it, it > > >> takes on a levity-polymorphic kind. For example, this: > > >> > > >> :k (->) Int# Int# > > >> > > >> would yield a kind error, but > > >> > > >> :k Int# -> Int# > > >> > > >> is okay. Now, if you want an explanation as to WHY that's the case, I > > >> don't think I could give one, as I simply got this information from > > >> [1] (see the fourth bullet point, for OpenKind). Perhaps SPJ or > > >> Richard Eisenberg could give a little insight here. > > >> > > >>> Also does this encapsulate the implicit impredicativity of ($) for > > making runST $ work? I don't presently see how it would. > > >> > > >> You're right, the impredicativity hack is a completely different > > >> thing. So while you won't be able to define your own ($) and be able > > >> to (runST $ do ...), you can at least define your own ($) and have it > > >> work with unlifted return types. :) > > >> > > >> Ryan S. > > >> ----- > > >> [1] https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds > > >> > > >> On Thu, Feb 4, 2016 at 2:53 PM, Christopher Allen > > wrote: > > >>> My understanding was that the implicitly polymorphic levity, did (->) > > not > > >>> change because it's a type constructor? > > >>> > > >>> Prelude> :info (->) > > >>> data (->) a b -- Defined in ?GHC.Prim? > > >>> Prelude> :k (->) > > >>> (->) :: * -> * -> * > > >>> > > >>> Basically I'm asking why ($) changed and (->) did not when (->) had > > similar > > >>> properties WRT * and #. > > >>> > > >>> Also does this encapsulate the implicit impredicativity of ($) for > > making > > >>> runST $ work? I don't presently see how it would. > > >>> > > >>> Worry not about the book, we already hand-wave FTP effectively. One > > more > > >>> type shouldn't change much. > > >>> > > >>> Thank you very much for answering, this has been very helpful already > > :) > > >>> > > >>> --- Chris > > >>> > > >>> > > >>> On Thu, Feb 4, 2016 at 12:52 PM, Ryan Scott > > wrote: > > >>>> > > >>>> Hi Chris, > > >>>> > > >>>> The change to ($)'s type is indeed intentional. The short answer is > > >>>> that ($)'s type prior to GHC 8.0 was lying a little bit. If you > > >>>> defined something like this: > > >>>> > > >>>> unwrapInt :: Int -> Int# > > >>>> unwrapInt (I# i) = i > > >>>> > > >>>> You could write an expression like (unwrapInt $ 42), and it would > > >>>> typecheck. But that technically shouldn't be happening, since ($) :: > > >>>> (a -> b) -> a -> b, and we all know that polymorphic types have to > > >>>> live in kind *. But if you look at unwrapInt :: Int -> Int#, the type > > >>>> Int# certainly doesn't live in *. So why is this happening? > > >>>> > > >>>> The long answer is that prior to GHC 8.0, in the type signature ($) :: > > >>>> (a -> b) -> a -> b, b actually wasn't in kind *, but rather OpenKind. > > >>>> OpenKind is an awful hack that allows both lifted (kind *) and > > >>>> unlifted (kind #) types to inhabit it, which is why (unwrapInt $ 42) > > >>>> typechecks. To get rid of the hackiness of OpenKind, Richard Eisenberg > > >>>> extended the type system with levity polymorphism [1] to indicate in > > >>>> the type signature where these kind of scenarios are happening. > > >>>> > > >>>> So in the "new" type signature for ($): > > >>>> > > >>>> ($) :: forall (w :: Levity) a (b :: TYPE w). (a -> b) -> a -> b > > >>>> > > >>>> The type b can either live in kind * (which is now a synonym for TYPE > > >>>> 'Lifted) or kind # (which is a synonym for TYPE 'Unlifted), which is > > >>>> indicated by the fact that TYPE w is polymorphic in its levity type w. > > >>>> > > >>>> Truth be told, there aren't that many Haskell functions that actually > > >>>> levity polymorphic, since normally having an argument type that could > > >>>> live in either * or # would wreak havoc with the RTS (otherwise, how > > >>>> would it know if it's dealing with a pointer or a value on the > > >>>> stack?). But as it turns out, it's perfectly okay to have a levity > > >>>> polymorphic type in a non-argument position [2]. Indeed, in the few > > >>>> levity polymorphic functions that I can think of: > > >>>> > > >>>> ($) :: forall (w :: Levity) a (b :: TYPE w). (a -> b) -> a > > -> b > > >>>> error :: forall (v :: Levity) (a :: TYPE v). HasCallStack => > > >>>> [Char] -> a > > >>>> undefined :: forall (v :: Levity) (a :: TYPE v). HasCallStack => a > > >>>> > > >>>> The levity polymorphic type never appears directly to the left of an > > >>>> arrow. > > >>>> > > >>>> The downside of all this is, of course, that the type signature of ($) > > >>>> might look a lot scarier to beginners. I'm not sure how you'd want to > > >>>> deal with this, but for 99% of most use cases, it's okay to lie and > > >>>> state that ($) :: (a -> b) -> a -> b. You might have to include a > > >>>> disclaimer that if they type :t ($) into GHCi, they should be prepared > > >>>> for some extra information! > > >>>> > > >>>> Ryan S. > > >>>> ----- > > >>>> [1] https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds > > >>>> [2] https://ghc.haskell.org/trac/ghc/ticket/11473 > > >>>> _______________________________________________ > > >>>> 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 > > >> _______________________________________________ > > >> ghc-devs mailing list > > >> ghc-devs at haskell.org > > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > >> > > > > > > _______________________________________________ > > > ghc-devs mailing list > > > ghc-devs at haskell.org > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > From cma at bitemyapp.com Thu Feb 4 23:38:46 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Thu, 4 Feb 2016 17:38:46 -0600 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: <1454628457-sup-7751@sabre> References: <0210F72D-CCF3-452A-BAD4-15796F288FD9@justtesting.org> <1454628457-sup-7751@sabre> Message-ID: The sort of pragma you suggest would satisfy me. Pragmas like this don't bother me and make my job a fair bit easier. Too many, "don't worry about this; later" is exhausting. Too many, "don't worry about this; we're not even going to have time to cover it" is demoralizing. On Thu, Feb 4, 2016 at 5:31 PM, Edward Z. Yang wrote: > I'm not really sure how you would change the type of 'id' based on > a language pragma. > > How do people feel about a cosmetic fix, where we introduce a new > pragma, {-# LANGUAGE ShowLevity #-} which controls the display of levity > arguments/TYPE. It's off by default but gets turned on by some > extensions like MagicHash (i.e. we only show levity if you have > enabled extensions where the distinction matters). > > Edward > > Excerpts from Christopher Allen's message of 2016-02-04 15:20:34 -0800: > > This seems worse than FTP IMO. It's considerably noisier, considerably > > rarer a concern for Haskell programmers, and is wayyyy beyond the scope > of > > most learning resources. > > > > Is there a reason this isn't behind a pragma? > > > > On Thu, Feb 4, 2016 at 5:02 PM, Manuel M T Chakravarty < > chak at justtesting.org > > > wrote: > > > > > To be honest, I think, it is quite problematic if an obscure and > untested > > > language extension (sorry, but that?s what it is right now) bleeds > through > > > into supposedly simple standard functionality. The beauty of most of > GHC?s > > > language extensions is that you can ignore them until you need them. > > > > > > Has this ever been discussed more widely? I expect that every single > > > person teaching Haskell is going to be unhappy about it. > > > > > > Manuel > > > > > > > > > > Richard Eisenberg : > > > > > > > > I agree with everything that's been said in this thread, including > the > > > unstated "that type for ($) is sure ugly". > > > > > > > > Currently, saturated (a -> b) is like a language construct, and it > has > > > its own typing rule, independent of the type of the type constructor > (->). > > > But reading the comment that Ben linked to, I think that comment is > out of > > > date. Now that we have levity polymorphism, we can probably to the > Right > > > Thing and make the kind of (->) more flexible. > > > > > > > > Richard > > > > > > > > On Feb 4, 2016, at 3:27 PM, Ryan Scott > wrote: > > > > > > > >>> My understanding was that the implicitly polymorphic levity, did > (->) > > > not change because it's a type constructor? > > > >> > > > >> The kind of (->) as GHCi reports it is technically correct. As a > kind > > > >> constructor, (->) has precisely the kind * -> * -> *. What's special > > > >> about (->) is that when you have a saturated application of it, it > > > >> takes on a levity-polymorphic kind. For example, this: > > > >> > > > >> :k (->) Int# Int# > > > >> > > > >> would yield a kind error, but > > > >> > > > >> :k Int# -> Int# > > > >> > > > >> is okay. Now, if you want an explanation as to WHY that's the case, > I > > > >> don't think I could give one, as I simply got this information from > > > >> [1] (see the fourth bullet point, for OpenKind). Perhaps SPJ or > > > >> Richard Eisenberg could give a little insight here. > > > >> > > > >>> Also does this encapsulate the implicit impredicativity of ($) for > > > making runST $ work? I don't presently see how it would. > > > >> > > > >> You're right, the impredicativity hack is a completely different > > > >> thing. So while you won't be able to define your own ($) and be able > > > >> to (runST $ do ...), you can at least define your own ($) and have > it > > > >> work with unlifted return types. :) > > > >> > > > >> Ryan S. > > > >> ----- > > > >> [1] https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds > > > >> > > > >> On Thu, Feb 4, 2016 at 2:53 PM, Christopher Allen < > cma at bitemyapp.com> > > > wrote: > > > >>> My understanding was that the implicitly polymorphic levity, did > (->) > > > not > > > >>> change because it's a type constructor? > > > >>> > > > >>> Prelude> :info (->) > > > >>> data (->) a b -- Defined in ?GHC.Prim? > > > >>> Prelude> :k (->) > > > >>> (->) :: * -> * -> * > > > >>> > > > >>> Basically I'm asking why ($) changed and (->) did not when (->) had > > > similar > > > >>> properties WRT * and #. > > > >>> > > > >>> Also does this encapsulate the implicit impredicativity of ($) for > > > making > > > >>> runST $ work? I don't presently see how it would. > > > >>> > > > >>> Worry not about the book, we already hand-wave FTP effectively. One > > > more > > > >>> type shouldn't change much. > > > >>> > > > >>> Thank you very much for answering, this has been very helpful > already > > > :) > > > >>> > > > >>> --- Chris > > > >>> > > > >>> > > > >>> On Thu, Feb 4, 2016 at 12:52 PM, Ryan Scott < > ryan.gl.scott at gmail.com> > > > wrote: > > > >>>> > > > >>>> Hi Chris, > > > >>>> > > > >>>> The change to ($)'s type is indeed intentional. The short answer > is > > > >>>> that ($)'s type prior to GHC 8.0 was lying a little bit. If you > > > >>>> defined something like this: > > > >>>> > > > >>>> unwrapInt :: Int -> Int# > > > >>>> unwrapInt (I# i) = i > > > >>>> > > > >>>> You could write an expression like (unwrapInt $ 42), and it would > > > >>>> typecheck. But that technically shouldn't be happening, since ($) > :: > > > >>>> (a -> b) -> a -> b, and we all know that polymorphic types have to > > > >>>> live in kind *. But if you look at unwrapInt :: Int -> Int#, the > type > > > >>>> Int# certainly doesn't live in *. So why is this happening? > > > >>>> > > > >>>> The long answer is that prior to GHC 8.0, in the type signature > ($) :: > > > >>>> (a -> b) -> a -> b, b actually wasn't in kind *, but rather > OpenKind. > > > >>>> OpenKind is an awful hack that allows both lifted (kind *) and > > > >>>> unlifted (kind #) types to inhabit it, which is why (unwrapInt $ > 42) > > > >>>> typechecks. To get rid of the hackiness of OpenKind, Richard > Eisenberg > > > >>>> extended the type system with levity polymorphism [1] to indicate > in > > > >>>> the type signature where these kind of scenarios are happening. > > > >>>> > > > >>>> So in the "new" type signature for ($): > > > >>>> > > > >>>> ($) :: forall (w :: Levity) a (b :: TYPE w). (a -> b) -> a -> b > > > >>>> > > > >>>> The type b can either live in kind * (which is now a synonym for > TYPE > > > >>>> 'Lifted) or kind # (which is a synonym for TYPE 'Unlifted), which > is > > > >>>> indicated by the fact that TYPE w is polymorphic in its levity > type w. > > > >>>> > > > >>>> Truth be told, there aren't that many Haskell functions that > actually > > > >>>> levity polymorphic, since normally having an argument type that > could > > > >>>> live in either * or # would wreak havoc with the RTS (otherwise, > how > > > >>>> would it know if it's dealing with a pointer or a value on the > > > >>>> stack?). But as it turns out, it's perfectly okay to have a levity > > > >>>> polymorphic type in a non-argument position [2]. Indeed, in the > few > > > >>>> levity polymorphic functions that I can think of: > > > >>>> > > > >>>> ($) :: forall (w :: Levity) a (b :: TYPE w). (a -> b) -> > a > > > -> b > > > >>>> error :: forall (v :: Levity) (a :: TYPE v). HasCallStack > => > > > >>>> [Char] -> a > > > >>>> undefined :: forall (v :: Levity) (a :: TYPE v). HasCallStack > => a > > > >>>> > > > >>>> The levity polymorphic type never appears directly to the left of > an > > > >>>> arrow. > > > >>>> > > > >>>> The downside of all this is, of course, that the type signature > of ($) > > > >>>> might look a lot scarier to beginners. I'm not sure how you'd > want to > > > >>>> deal with this, but for 99% of most use cases, it's okay to lie > and > > > >>>> state that ($) :: (a -> b) -> a -> b. You might have to include a > > > >>>> disclaimer that if they type :t ($) into GHCi, they should be > prepared > > > >>>> for some extra information! > > > >>>> > > > >>>> Ryan S. > > > >>>> ----- > > > >>>> [1] https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds > > > >>>> [2] https://ghc.haskell.org/trac/ghc/ticket/11473 > > > >>>> _______________________________________________ > > > >>>> 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 > > > >> _______________________________________________ > > > >> ghc-devs mailing list > > > >> ghc-devs at haskell.org > > > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > >> > > > > > > > > _______________________________________________ > > > > ghc-devs mailing list > > > > ghc-devs at haskell.org > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > > _______________________________________________ > > > ghc-devs mailing list > > > ghc-devs at haskell.org > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > > -- Chris Allen Currently working on http://haskellbook.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Thu Feb 4 23:59:22 2016 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Thu, 4 Feb 2016 17:59:22 -0600 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: References: <0210F72D-CCF3-452A-BAD4-15796F288FD9@justtesting.org> <1454628457-sup-7751@sabre> Message-ID: Hello, how about we simply use two operators: 1. ($) which only works for standard types (i.e., not #), which we can use 99% of the time, and 2. some other operator which has the levity polymorphic type and would be used in the advanced cases when you are working with unboxed values, etc. Personally, I use unboxed values rarely enough, that I'd even be OK simply using parens or naming the sub-expression instead of using $ -Iavor On Thu, Feb 4, 2016 at 5:38 PM, Christopher Allen wrote: > The sort of pragma you suggest would satisfy me. Pragmas like this don't > bother me and make my job a fair bit easier. Too many, "don't worry about > this; later" is exhausting. Too many, "don't worry about this; we're not > even going to have time to cover it" is demoralizing. > > On Thu, Feb 4, 2016 at 5:31 PM, Edward Z. Yang wrote: > >> I'm not really sure how you would change the type of 'id' based on >> a language pragma. >> >> How do people feel about a cosmetic fix, where we introduce a new >> pragma, {-# LANGUAGE ShowLevity #-} which controls the display of levity >> arguments/TYPE. It's off by default but gets turned on by some >> extensions like MagicHash (i.e. we only show levity if you have >> enabled extensions where the distinction matters). >> >> Edward >> >> Excerpts from Christopher Allen's message of 2016-02-04 15:20:34 -0800: >> > This seems worse than FTP IMO. It's considerably noisier, considerably >> > rarer a concern for Haskell programmers, and is wayyyy beyond the scope >> of >> > most learning resources. >> > >> > Is there a reason this isn't behind a pragma? >> > >> > On Thu, Feb 4, 2016 at 5:02 PM, Manuel M T Chakravarty < >> chak at justtesting.org >> > > wrote: >> > >> > > To be honest, I think, it is quite problematic if an obscure and >> untested >> > > language extension (sorry, but that?s what it is right now) bleeds >> through >> > > into supposedly simple standard functionality. The beauty of most of >> GHC?s >> > > language extensions is that you can ignore them until you need them. >> > > >> > > Has this ever been discussed more widely? I expect that every single >> > > person teaching Haskell is going to be unhappy about it. >> > > >> > > Manuel >> > > >> > > >> > > > Richard Eisenberg : >> > > > >> > > > I agree with everything that's been said in this thread, including >> the >> > > unstated "that type for ($) is sure ugly". >> > > > >> > > > Currently, saturated (a -> b) is like a language construct, and it >> has >> > > its own typing rule, independent of the type of the type constructor >> (->). >> > > But reading the comment that Ben linked to, I think that comment is >> out of >> > > date. Now that we have levity polymorphism, we can probably to the >> Right >> > > Thing and make the kind of (->) more flexible. >> > > > >> > > > Richard >> > > > >> > > > On Feb 4, 2016, at 3:27 PM, Ryan Scott >> wrote: >> > > > >> > > >>> My understanding was that the implicitly polymorphic levity, did >> (->) >> > > not change because it's a type constructor? >> > > >> >> > > >> The kind of (->) as GHCi reports it is technically correct. As a >> kind >> > > >> constructor, (->) has precisely the kind * -> * -> *. What's >> special >> > > >> about (->) is that when you have a saturated application of it, it >> > > >> takes on a levity-polymorphic kind. For example, this: >> > > >> >> > > >> :k (->) Int# Int# >> > > >> >> > > >> would yield a kind error, but >> > > >> >> > > >> :k Int# -> Int# >> > > >> >> > > >> is okay. Now, if you want an explanation as to WHY that's the >> case, I >> > > >> don't think I could give one, as I simply got this information from >> > > >> [1] (see the fourth bullet point, for OpenKind). Perhaps SPJ or >> > > >> Richard Eisenberg could give a little insight here. >> > > >> >> > > >>> Also does this encapsulate the implicit impredicativity of ($) for >> > > making runST $ work? I don't presently see how it would. >> > > >> >> > > >> You're right, the impredicativity hack is a completely different >> > > >> thing. So while you won't be able to define your own ($) and be >> able >> > > >> to (runST $ do ...), you can at least define your own ($) and have >> it >> > > >> work with unlifted return types. :) >> > > >> >> > > >> Ryan S. >> > > >> ----- >> > > >> [1] https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds >> > > >> >> > > >> On Thu, Feb 4, 2016 at 2:53 PM, Christopher Allen < >> cma at bitemyapp.com> >> > > wrote: >> > > >>> My understanding was that the implicitly polymorphic levity, did >> (->) >> > > not >> > > >>> change because it's a type constructor? >> > > >>> >> > > >>> Prelude> :info (->) >> > > >>> data (->) a b -- Defined in ?GHC.Prim? >> > > >>> Prelude> :k (->) >> > > >>> (->) :: * -> * -> * >> > > >>> >> > > >>> Basically I'm asking why ($) changed and (->) did not when (->) >> had >> > > similar >> > > >>> properties WRT * and #. >> > > >>> >> > > >>> Also does this encapsulate the implicit impredicativity of ($) for >> > > making >> > > >>> runST $ work? I don't presently see how it would. >> > > >>> >> > > >>> Worry not about the book, we already hand-wave FTP effectively. >> One >> > > more >> > > >>> type shouldn't change much. >> > > >>> >> > > >>> Thank you very much for answering, this has been very helpful >> already >> > > :) >> > > >>> >> > > >>> --- Chris >> > > >>> >> > > >>> >> > > >>> On Thu, Feb 4, 2016 at 12:52 PM, Ryan Scott < >> ryan.gl.scott at gmail.com> >> > > wrote: >> > > >>>> >> > > >>>> Hi Chris, >> > > >>>> >> > > >>>> The change to ($)'s type is indeed intentional. The short answer >> is >> > > >>>> that ($)'s type prior to GHC 8.0 was lying a little bit. If you >> > > >>>> defined something like this: >> > > >>>> >> > > >>>> unwrapInt :: Int -> Int# >> > > >>>> unwrapInt (I# i) = i >> > > >>>> >> > > >>>> You could write an expression like (unwrapInt $ 42), and it would >> > > >>>> typecheck. But that technically shouldn't be happening, since >> ($) :: >> > > >>>> (a -> b) -> a -> b, and we all know that polymorphic types have >> to >> > > >>>> live in kind *. But if you look at unwrapInt :: Int -> Int#, the >> type >> > > >>>> Int# certainly doesn't live in *. So why is this happening? >> > > >>>> >> > > >>>> The long answer is that prior to GHC 8.0, in the type signature >> ($) :: >> > > >>>> (a -> b) -> a -> b, b actually wasn't in kind *, but rather >> OpenKind. >> > > >>>> OpenKind is an awful hack that allows both lifted (kind *) and >> > > >>>> unlifted (kind #) types to inhabit it, which is why (unwrapInt $ >> 42) >> > > >>>> typechecks. To get rid of the hackiness of OpenKind, Richard >> Eisenberg >> > > >>>> extended the type system with levity polymorphism [1] to >> indicate in >> > > >>>> the type signature where these kind of scenarios are happening. >> > > >>>> >> > > >>>> So in the "new" type signature for ($): >> > > >>>> >> > > >>>> ($) :: forall (w :: Levity) a (b :: TYPE w). (a -> b) -> a -> b >> > > >>>> >> > > >>>> The type b can either live in kind * (which is now a synonym for >> TYPE >> > > >>>> 'Lifted) or kind # (which is a synonym for TYPE 'Unlifted), >> which is >> > > >>>> indicated by the fact that TYPE w is polymorphic in its levity >> type w. >> > > >>>> >> > > >>>> Truth be told, there aren't that many Haskell functions that >> actually >> > > >>>> levity polymorphic, since normally having an argument type that >> could >> > > >>>> live in either * or # would wreak havoc with the RTS (otherwise, >> how >> > > >>>> would it know if it's dealing with a pointer or a value on the >> > > >>>> stack?). But as it turns out, it's perfectly okay to have a >> levity >> > > >>>> polymorphic type in a non-argument position [2]. Indeed, in the >> few >> > > >>>> levity polymorphic functions that I can think of: >> > > >>>> >> > > >>>> ($) :: forall (w :: Levity) a (b :: TYPE w). (a -> b) >> -> a >> > > -> b >> > > >>>> error :: forall (v :: Levity) (a :: TYPE v). HasCallStack >> => >> > > >>>> [Char] -> a >> > > >>>> undefined :: forall (v :: Levity) (a :: TYPE v). HasCallStack >> => a >> > > >>>> >> > > >>>> The levity polymorphic type never appears directly to the left >> of an >> > > >>>> arrow. >> > > >>>> >> > > >>>> The downside of all this is, of course, that the type signature >> of ($) >> > > >>>> might look a lot scarier to beginners. I'm not sure how you'd >> want to >> > > >>>> deal with this, but for 99% of most use cases, it's okay to lie >> and >> > > >>>> state that ($) :: (a -> b) -> a -> b. You might have to include a >> > > >>>> disclaimer that if they type :t ($) into GHCi, they should be >> prepared >> > > >>>> for some extra information! >> > > >>>> >> > > >>>> Ryan S. >> > > >>>> ----- >> > > >>>> [1] https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds >> > > >>>> [2] https://ghc.haskell.org/trac/ghc/ticket/11473 >> > > >>>> _______________________________________________ >> > > >>>> 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 >> > > >> _______________________________________________ >> > > >> ghc-devs mailing list >> > > >> ghc-devs at haskell.org >> > > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > >> >> > > > >> > > > _______________________________________________ >> > > > ghc-devs mailing list >> > > > ghc-devs at haskell.org >> > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > >> > > _______________________________________________ >> > > ghc-devs mailing list >> > > ghc-devs at haskell.org >> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > >> > >> > > > > -- > Chris Allen > Currently working on http://haskellbook.com > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Fri Feb 5 06:46:26 2016 From: ekmett at gmail.com (Edward Kmett) Date: Fri, 5 Feb 2016 01:46:26 -0500 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: References: Message-ID: Note: (->) is a type. ($) is a term. There is still magic in the typechecker around allowing fully saturated applications of (x -> y) allowing x and y to be in either # or *. My understanding is that (->) isn't really truly levity-polymorphic, but rather acts differently based on the levity of the argument. Think of it this way, if you look at what happens on the stack, based on the kind of the argument and the kind of the result, a value of the type (x -> y) acts very differently. Similarly there remain hacks for (x, y) allows x or y to be (both) * or Constraint through another hack, and () :: Constraint typechecks despite () :: * being the default interpretation. ($) and other truly levity polymorphic functions are fortunate in that they don't need any such magic hacks and don't care. -Edward On Thu, Feb 4, 2016 at 2:53 PM, Christopher Allen wrote: > My understanding was that the implicitly polymorphic levity, did (->) not > change because it's a type constructor? > > Prelude> :info (->) > data (->) a b -- Defined in ?GHC.Prim? > Prelude> :k (->) > (->) :: * -> * -> * > > Basically I'm asking why ($) changed and (->) did not when (->) had > similar properties WRT * and #. > > Also does this encapsulate the implicit impredicativity of ($) for making > runST $ work? I don't presently see how it would. > > Worry not about the book, we already hand-wave FTP effectively. One more > type shouldn't change much. > > Thank you very much for answering, this has been very helpful already :) > > --- Chris > > > On Thu, Feb 4, 2016 at 12:52 PM, Ryan Scott > wrote: > >> Hi Chris, >> >> The change to ($)'s type is indeed intentional. The short answer is >> that ($)'s type prior to GHC 8.0 was lying a little bit. If you >> defined something like this: >> >> unwrapInt :: Int -> Int# >> unwrapInt (I# i) = i >> >> You could write an expression like (unwrapInt $ 42), and it would >> typecheck. But that technically shouldn't be happening, since ($) :: >> (a -> b) -> a -> b, and we all know that polymorphic types have to >> live in kind *. But if you look at unwrapInt :: Int -> Int#, the type >> Int# certainly doesn't live in *. So why is this happening? >> >> The long answer is that prior to GHC 8.0, in the type signature ($) :: >> (a -> b) -> a -> b, b actually wasn't in kind *, but rather OpenKind. >> OpenKind is an awful hack that allows both lifted (kind *) and >> unlifted (kind #) types to inhabit it, which is why (unwrapInt $ 42) >> typechecks. To get rid of the hackiness of OpenKind, Richard Eisenberg >> extended the type system with levity polymorphism [1] to indicate in >> the type signature where these kind of scenarios are happening. >> >> So in the "new" type signature for ($): >> >> ($) :: forall (w :: Levity) a (b :: TYPE w). (a -> b) -> a -> b >> >> The type b can either live in kind * (which is now a synonym for TYPE >> 'Lifted) or kind # (which is a synonym for TYPE 'Unlifted), which is >> indicated by the fact that TYPE w is polymorphic in its levity type w. >> >> Truth be told, there aren't that many Haskell functions that actually >> levity polymorphic, since normally having an argument type that could >> live in either * or # would wreak havoc with the RTS (otherwise, how >> would it know if it's dealing with a pointer or a value on the >> stack?). But as it turns out, it's perfectly okay to have a levity >> polymorphic type in a non-argument position [2]. Indeed, in the few >> levity polymorphic functions that I can think of: >> >> ($) :: forall (w :: Levity) a (b :: TYPE w). (a -> b) -> a -> b >> error :: forall (v :: Levity) (a :: TYPE v). HasCallStack => >> [Char] -> a >> undefined :: forall (v :: Levity) (a :: TYPE v). HasCallStack => a >> >> The levity polymorphic type never appears directly to the left of an >> arrow. >> >> The downside of all this is, of course, that the type signature of ($) >> might look a lot scarier to beginners. I'm not sure how you'd want to >> deal with this, but for 99% of most use cases, it's okay to lie and >> state that ($) :: (a -> b) -> a -> b. You might have to include a >> disclaimer that if they type :t ($) into GHCi, they should be prepared >> for some extra information! >> >> Ryan S. >> ----- >> [1] https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds >> [2] https://ghc.haskell.org/trac/ghc/ticket/11473 >> _______________________________________________ >> 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 > > _______________________________________________ > 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 roma at ro-che.info Fri Feb 5 07:22:54 2016 From: roma at ro-che.info (Roman Cheplyaka) Date: Fri, 5 Feb 2016 09:22:54 +0200 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: <1454628457-sup-7751@sabre> References: <0210F72D-CCF3-452A-BAD4-15796F288FD9@justtesting.org> <1454628457-sup-7751@sabre> Message-ID: <56B44DCE.5010602@ro-che.info> On 02/05/2016 01:31 AM, Edward Z. Yang wrote: > I'm not really sure how you would change the type of 'id' based on > a language pragma. > > How do people feel about a cosmetic fix, where we introduce a new > pragma, {-# LANGUAGE ShowLevity #-} which controls the display of levity > arguments/TYPE. It's off by default but gets turned on by some > extensions like MagicHash (i.e. we only show levity if you have > enabled extensions where the distinction matters). Yes, I am surprised this isn't the way it's been done. The levity arguments should totally be hidden unless requested explicitly. I'd only expect this to be a ghc flag (-fshow-levity), not a language pragma, since it should only affect the way types are /shown/. Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From mail at joachim-breitner.de Fri Feb 5 09:19:26 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 05 Feb 2016 10:19:26 +0100 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: <56B44DCE.5010602@ro-che.info> References: <0210F72D-CCF3-452A-BAD4-15796F288FD9@justtesting.org> <1454628457-sup-7751@sabre> <56B44DCE.5010602@ro-che.info> Message-ID: <1454663966.1570.1.camel@joachim-breitner.de> Hi, Am Freitag, den 05.02.2016, 09:22 +0200 schrieb Roman Cheplyaka: > On 02/05/2016 01:31 AM, Edward Z. Yang wrote: > > I'm not really sure how you would change the type of 'id' based on > > a language pragma. > > > > How do people feel about a cosmetic fix, where we introduce a new > > pragma, {-# LANGUAGE ShowLevity #-} which controls the display of > > levity > > arguments/TYPE.??It's off by default but gets turned on by some > > extensions like MagicHash (i.e. we only show levity if you have > > enabled extensions where the distinction matters). > > Yes, I am surprised this isn't the way it's been done. The levity > arguments should totally be hidden unless requested explicitly. > > I'd only expect this to be a ghc flag (-fshow-levity), not a language > pragma, since it should only affect the way types are /shown/. shouldn?t this already happen, based on?-fprint-explicit-kinds? At least I would have expected this. So we probably either want to make sure that -fno-print-explicit-kinds also prevents forall?ed kind variables, or add a new flag of that (heh) kind. 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 takenobu.hs at gmail.com Fri Feb 5 13:16:40 2016 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Fri, 5 Feb 2016 22:16:40 +0900 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: <1454663966.1570.1.camel@joachim-breitner.de> References: <0210F72D-CCF3-452A-BAD4-15796F288FD9@justtesting.org> <1454628457-sup-7751@sabre> <56B44DCE.5010602@ro-che.info> <1454663966.1570.1.camel@joachim-breitner.de> Message-ID: Hi, I'll worry about the learning curve of beginners. Maybe, beginners will try following session in their 1st week. ghci> :t foldr ghci> :t ($) They'll get following result. Before ghc7.8: Prelude> :t foldr foldr :: (a -> b -> b) -> b -> [a] -> b Prelude> :t ($) ($) :: (a -> b) -> a -> b Beginners should only understand about following: * type variable (polymorphism) After ghc8.0: Prelude> :t foldr foldr :: Foldable t => (a -> b -> b) -> b -> t a -> b Prelude> :t ($) ($) :: forall (w :: GHC.Types.Levity) a (b :: TYPE w). (a -> b) -> a -> b Beginners should understand about following things, more: * higher order polymorphism (t m) * type class (class t =>) * universal quantification (forall) * kind (type::kind) * levity (lifted/unlifted) I think it's harder in their 1st week. I tried to draw informal illustrations about Foldable, but beginners may need ghci-beginner?s mode or something? Sorry I don't still have good idea. Of course I like Haskell's abstraction :) Regards, Takenobu 2016-02-05 18:19 GMT+09:00 Joachim Breitner : > Hi, > > Am Freitag, den 05.02.2016, 09:22 +0200 schrieb Roman Cheplyaka: > > On 02/05/2016 01:31 AM, Edward Z. Yang wrote: > > > I'm not really sure how you would change the type of 'id' based on > > > a language pragma. > > > > > > How do people feel about a cosmetic fix, where we introduce a new > > > pragma, {-# LANGUAGE ShowLevity #-} which controls the display of > > > levity > > > arguments/TYPE. It's off by default but gets turned on by some > > > extensions like MagicHash (i.e. we only show levity if you have > > > enabled extensions where the distinction matters). > > > > Yes, I am surprised this isn't the way it's been done. The levity > > arguments should totally be hidden unless requested explicitly. > > > > I'd only expect this to be a ghc flag (-fshow-levity), not a language > > pragma, since it should only affect the way types are /shown/. > > shouldn?t this already happen, based on -fprint-explicit-kinds? At > least I would have expected this. > > So we probably either want to make sure that -fno-print-explicit-kinds > also prevents forall?ed kind variables, or add a new flag of that (heh) > kind. > > Greetings, > Joachim > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Fri Feb 5 13:49:35 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 5 Feb 2016 08:49:35 -0500 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: References: <0210F72D-CCF3-452A-BAD4-15796F288FD9@justtesting.org> <1454628457-sup-7751@sabre> <56B44DCE.5010602@ro-che.info> <1454663966.1570.1.camel@joachim-breitner.de> Message-ID: <305900D6-F152-4670-9EA1-6F33D6A63D67@cis.upenn.edu> As the instigator of these most recent changes: - Yes, absolutely, ($)'s type is quite ugly. In other areas, I've tried to hide the newfound complexity in the type system behind flags, but I missed this one. I consider the current output to be a bug. - It's conceivable to have a flag -fdefault-levity, on by default, which looks for levity polymorphism while printing and instantiates all levity variables to Lifted before printing. That would fix the type of ($). Of course, users could specify -fno-default-levity. Would this make you happy? - There's a real drawback to flags like -fdefault-levity (and, relatedly, -fprint-explicit-kinds, -fprint-explicit-foralls, -fprint-explicit-coercions, -fprint-equality-relations; the last two are new in 8.0): they hide things from unsuspecting users. We already get a steady trickle of bug reports stemming from confusion around hidden kinds. Users diligently try to make a minimal test case and then someone has to point out that the user is wrong. It's a waste of time and, I'm sure, is frustrating for users. I'm worried about this problem getting worse. - It's interesting that the solution to the two problems Takenobu pulls out below (but others have hinted at in this thread) is by having an alternate Prelude for beginners. I believe that having an alternate beginners' Prelude is becoming essential. I know I'm not the first one to suggest this, but a great many issues that teachers of Haskell have raised with me and posts on this and other lists would be solved by an alternate Prelude for beginners. - Separate from a full alternate Prelude, and as Iavor suggested, we could just have two ($) operators: a simple one with no baked-in magic or levity polymorphism, and then a levity-polymorphic, sneakily impredicative one. This would be dead easy. - Edward is right in that (->) isn't really levity-polymorphic. Well, it is, but it's ad hoc polymorphism not parametric polymorphism. Perhaps in the future we'll make this more robust by actually using type-classes to control it, as we probably should. - The case with (->) is different than that with (). (() :: Constraint) and (() :: *) are wholly unrelated types. () is not constraintyness-polymorphic. It's just that we have two wholly unrelated types that happen to share a spelling. So there are hacks in the compiler to disambiguate. Sometimes these hacks do the wrong thing. If we had type-directed name resolution (which I'm not proposing to have!), this would get resolved nicely. - The reason that the foralls get printed in ($)'s type is that kind variables appear in the type variables' kinds. GHC thinks that printing the foralls are useful in this case and does so without a flag. This is not directly related to the levity piece. If you say `:t Proxy`, you'll get similar behavior. Bottom line: We *need* an alternate Prelude. But that won't happen for 8.0. So in the meantime, I propose -fdefault-levity, awaiting your approval. Richard On Feb 5, 2016, at 8:16 AM, Takenobu Tani wrote: > Hi, > > I'll worry about the learning curve of beginners. > Maybe, beginners will try following session in their 1st week. > > ghci> :t foldr > ghci> :t ($) > > They'll get following result. > > > Before ghc7.8: > > Prelude> :t foldr > foldr :: (a -> b -> b) -> b -> [a] -> b > > Prelude> :t ($) > ($) :: (a -> b) -> a -> b > > Beginners should only understand about following: > > * type variable (polymorphism) > > > After ghc8.0: > > Prelude> :t foldr > foldr :: Foldable t => (a -> b -> b) -> b -> t a -> b > > Prelude> :t ($) > ($) > :: forall (w :: GHC.Types.Levity) a (b :: TYPE w). > (a -> b) -> a -> b > > Beginners should understand about following things, more: > > * higher order polymorphism (t m) > * type class (class t =>) > * universal quantification (forall) > * kind (type::kind) > * levity (lifted/unlifted) > > I think it's harder in their 1st week. > I tried to draw informal illustrations about Foldable, > but beginners may need ghci-beginner?s mode or something? > > Sorry I don't still have good idea. > > Of course I like Haskell's abstraction :) > > Regards, > Takenobu > > > 2016-02-05 18:19 GMT+09:00 Joachim Breitner : > Hi, > > Am Freitag, den 05.02.2016, 09:22 +0200 schrieb Roman Cheplyaka: > > On 02/05/2016 01:31 AM, Edward Z. Yang wrote: > > > I'm not really sure how you would change the type of 'id' based on > > > a language pragma. > > > > > > How do people feel about a cosmetic fix, where we introduce a new > > > pragma, {-# LANGUAGE ShowLevity #-} which controls the display of > > > levity > > > arguments/TYPE. It's off by default but gets turned on by some > > > extensions like MagicHash (i.e. we only show levity if you have > > > enabled extensions where the distinction matters). > > > > Yes, I am surprised this isn't the way it's been done. The levity > > arguments should totally be hidden unless requested explicitly. > > > > I'd only expect this to be a ghc flag (-fshow-levity), not a language > > pragma, since it should only affect the way types are /shown/. > > shouldn?t this already happen, based on -fprint-explicit-kinds? At > least I would have expected this. > > So we probably either want to make sure that -fno-print-explicit-kinds > also prevents forall?ed kind variables, or add a new flag of that (heh) > kind. > > 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 > > > _______________________________________________ > 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 Fri Feb 5 16:36:32 2016 From: dan.doel at gmail.com (Dan Doel) Date: Fri, 5 Feb 2016 11:36:32 -0500 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: <305900D6-F152-4670-9EA1-6F33D6A63D67@cis.upenn.edu> References: <0210F72D-CCF3-452A-BAD4-15796F288FD9@justtesting.org> <1454628457-sup-7751@sabre> <56B44DCE.5010602@ro-che.info> <1454663966.1570.1.camel@joachim-breitner.de> <305900D6-F152-4670-9EA1-6F33D6A63D67@cis.upenn.edu> Message-ID: I have a side question and some possible alternate views on a couple things. The first is: is the fancy type of ($) actually used? It has additional special type checking behavior that isn't captured in that type (impredicative instantiation), but probably in a separate code path. Does that only happen when it's saturated or something, and this is for partial applications? Second, it seems like () being overloaded is exactly like type classes, and (->) is less clearly in that camp (it seems more like a gadt). Just, we don't have classes at the level necessary to handle (). -- Dan On Feb 5, 2016 8:49 AM, "Richard Eisenberg" wrote: > As the instigator of these most recent changes: > > - Yes, absolutely, ($)'s type is quite ugly. In other areas, I've tried to > hide the newfound complexity in the type system behind flags, but I missed > this one. I consider the current output to be a bug. > > - It's conceivable to have a flag -fdefault-levity, on by default, which > looks for levity polymorphism while printing and instantiates all levity > variables to Lifted before printing. That would fix the type of ($). Of > course, users could specify -fno-default-levity. Would this make you happy? > > - There's a real drawback to flags like -fdefault-levity (and, relatedly, > -fprint-explicit-kinds, -fprint-explicit-foralls, > -fprint-explicit-coercions, -fprint-equality-relations; the last two are > new in 8.0): they hide things from unsuspecting users. We already get a > steady trickle of bug reports stemming from confusion around hidden kinds. > Users diligently try to make a minimal test case and then someone has to > point out that the user is wrong. It's a waste of time and, I'm sure, is > frustrating for users. I'm worried about this problem getting worse. > > - It's interesting that the solution to the two problems Takenobu pulls > out below (but others have hinted at in this thread) is by having an > alternate Prelude for beginners. I believe that having an alternate > beginners' Prelude is becoming essential. I know I'm not the first one to > suggest this, but a great many issues that teachers of Haskell have raised > with me and posts on this and other lists would be solved by an alternate > Prelude for beginners. > > - Separate from a full alternate Prelude, and as Iavor suggested, we could > just have two ($) operators: a simple one with no baked-in magic or levity > polymorphism, and then a levity-polymorphic, sneakily impredicative one. > This would be dead easy. > > - Edward is right in that (->) isn't really levity-polymorphic. Well, it > is, but it's ad hoc polymorphism not parametric polymorphism. Perhaps in > the future we'll make this more robust by actually using type-classes to > control it, as we probably should. > > - The case with (->) is different than that with (). (() :: Constraint) > and (() :: *) are wholly unrelated types. () is not > constraintyness-polymorphic. It's just that we have two wholly unrelated > types that happen to share a spelling. So there are hacks in the compiler > to disambiguate. Sometimes these hacks do the wrong thing. If we had > type-directed name resolution (which I'm not proposing to have!), this > would get resolved nicely. > > - The reason that the foralls get printed in ($)'s type is that kind > variables appear in the type variables' kinds. GHC thinks that printing the > foralls are useful in this case and does so without a flag. This is not > directly related to the levity piece. If you say `:t Proxy`, you'll get > similar behavior. > > > Bottom line: We *need* an alternate Prelude. But that won't happen for > 8.0. So in the meantime, I propose -fdefault-levity, awaiting your approval. > > Richard > > On Feb 5, 2016, at 8:16 AM, Takenobu Tani wrote: > > Hi, > > I'll worry about the learning curve of beginners. > Maybe, beginners will try following session in their 1st week. > > ghci> :t foldr > ghci> :t ($) > > They'll get following result. > > > Before ghc7.8: > > Prelude> :t foldr > foldr :: (a -> b -> b) -> b -> [a] -> b > > Prelude> :t ($) > ($) :: (a -> b) -> a -> b > > Beginners should only understand about following: > > * type variable (polymorphism) > > > After ghc8.0: > > Prelude> :t foldr > foldr :: Foldable t => (a -> b -> b) -> b -> t a -> b > > Prelude> :t ($) > ($) > :: forall (w :: GHC.Types.Levity) a (b :: TYPE w). > (a -> b) -> a -> b > > Beginners should understand about following things, more: > > * higher order polymorphism (t m) > * type class (class t =>) > * universal quantification (forall) > * kind (type::kind) > * levity (lifted/unlifted) > > I think it's harder in their 1st week. > I tried to draw informal illustrations about Foldable, > but beginners may need ghci-beginner?s mode or something? > > Sorry I don't still have good idea. > > Of course I like Haskell's abstraction :) > > Regards, > Takenobu > > > 2016-02-05 18:19 GMT+09:00 Joachim Breitner : > >> Hi, >> >> Am Freitag, den 05.02.2016, 09:22 +0200 schrieb Roman Cheplyaka: >> > On 02/05/2016 01:31 AM, Edward Z. Yang wrote: >> > > I'm not really sure how you would change the type of 'id' based on >> > > a language pragma. >> > > >> > > How do people feel about a cosmetic fix, where we introduce a new >> > > pragma, {-# LANGUAGE ShowLevity #-} which controls the display of >> > > levity >> > > arguments/TYPE. It's off by default but gets turned on by some >> > > extensions like MagicHash (i.e. we only show levity if you have >> > > enabled extensions where the distinction matters). >> > >> > Yes, I am surprised this isn't the way it's been done. The levity >> > arguments should totally be hidden unless requested explicitly. >> > >> > I'd only expect this to be a ghc flag (-fshow-levity), not a language >> > pragma, since it should only affect the way types are /shown/. >> >> shouldn?t this already happen, based on -fprint-explicit-kinds? At >> least I would have expected this. >> >> So we probably either want to make sure that -fno-print-explicit-kinds >> also prevents forall?ed kind variables, or add a new flag of that (heh) >> kind. >> >> 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 >> >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Fri Feb 5 18:13:23 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 5 Feb 2016 13:13:23 -0500 Subject: [Haskell-cafe] New type of ($) operator in GHC 8.0 is problematic In-Reply-To: References: <56B4CA58.4050101@htwk-leipzig.de> <56B4CCEB.5060406@htwk-leipzig.de> <20160205162651.GA28854@weber> Message-ID: <6B40AE7F-84DE-48A2-83FF-1940786CFC1F@cis.upenn.edu> Perhaps it will aid the discussion to see that the type of ($) will, for better or worse, be changing again before 8.0. The problem is described in GHC ticket #11471. The details of "why" aren't all that important for this discussion, but the resolution might be. The new (hopefully final!) type of ($) will be: > ($) :: forall (r :: RuntimeRep) (a :: *) (b :: TYPE r). (a -> b) -> a -> b Once again, it's easy enough to tweak the pretty-printer to hide the complexity. But perhaps it's not necessary. The difference as far as this conversation is concerned is that Levity has been renamed to RuntimeRep. I think this is an improvement, because now it's not terribly hard to explain: --- 1. Types of kind * have values represented by pointers. This is the vast majority of data in Haskell, because almost everything in Haskell is boxed. 2. But sometimes, we don't care how a value is represented. In this case, we can be polymorphic in the choice of representation, just like `length` is polymorphic in the choice of list element type. 3. ($) works with functions whose result can have any representation, as succinctly stated in the type. Note that the argument to the function must be boxed, however, because the implementation of ($) must store and pass the argument. It doesn't care at all about the result, though, allowing for representation-polymorphism. In aid of this explanation, we can relate this all to Java. The reference types in Java (e.g., Object, int[], Boolean) are all like types of kind *. The primitive types in Java (int, boolean, char) do not have kind *. Java allows type abstraction (that is, generics) only over the types of kind *. Haskell is more general, allowing abstraction over primitive types via representation polymorphism. --- Could this all be explained to a novice programmer? That would be a struggle. But it could indeed be explained to an intermediate programmer in another language just learning Haskell. For point of comparison, Java is widely used as a teaching language. And yet one of the simplest programs is public class HelloWorld { public static void main(String[] args) { System.out.println("Hello, world!"); } } When I taught Java (I taught high-school full time for 8 years), I would start with something similar to this and have to tell everyone to ignore 90% of what was written. My course never even got to arrays and `static`! That was painful, but everyone survived. This is just to point out that Haskell isn't the only language with this problem. Not to say we shouldn't try to improve! We're in a bit of a bind in all this. We really need the fancy type for ($) so that it can be used in all situations where it is used currently. The old type for ($) was just a plain old lie. Now, at least, we're not lying. So, do we 1) lie, 2) allow the language to grow, or 3) avoid certain growth because it affects how easy the language is to learn? I don't really think anyone is advocating for (3) exactly, but it's hard to have (2) and not make things more complicated -- unless we have a beginners' mode or other features in, say, GHCi that aid learning. As I've said, I'm in full favor of adding these features. Richard On Feb 5, 2016, at 12:55 PM, Kyle Hanson wrote: > I am also happy the discussion was posted here. Although I don't teach Haskell professionally, one of the things I loved to do was show people how simple Haskell really was by inspecting types and slowly putting the puzzle pieces together. > > Summary of the problem for others: > From Takenobu Tani > Before ghc7.8: > > Prelude> :t foldr > foldr :: (a -> b -> b) -> b -> [a] -> b > > Prelude> :t ($) > ($) :: (a -> b) -> a -> b > > Beginners should only understand about following: > > * type variable (polymorphism) > > > After ghc8.0: > > Prelude> :t foldr > foldr :: Foldable t => (a -> b -> b) -> b -> t a -> b > > Prelude> :t ($) > ($) > :: forall (w :: GHC.Types.Levity) a (b :: TYPE w). > (a -> b) -> a -> b > > > With this change it looks like I will no longer be able to keep `$` in my toolbox since telling a beginner its "magic" goes against what I believe Haskell is good at, being well defined and easy to understand (Not well defined in terms of Types but well defined in terms of ability to precisely and concisely explain and define whats going on). > > It looks like where the discussion is going is to have these types show by default but eventually have an Alternative prelude for beginners. > > From Richard Eisenberg: > - It's interesting that the solution to the two problems Takenobu pulls out below (but others have hinted at in this thread) is by having an alternate Prelude for beginners. I believe that having an alternate beginners' Prelude is becoming essential. I know I'm not the first one to suggest this, but a great many issues that teachers of Haskell have raised with me and posts on this and other lists would be solved by an alternate Prelude for beginners. > I don't like the idea of fragmenting Haskell into "beginners" and "advanced" versions. Its hard enough to get people to believe Haskell is easy. If they see that they aren't using the "real" prelude, Haskell will still be this magic black box that is too abstract and difficult to understand. If they have to use a "dumbed down" version of Haskell to learn, its not as compelling. > > There is something powerful about using the same idiomatic tools as the "big boys" and have the tools still be able to be easy to understand.... by default. Adding complexity to the default Haskell runs the risk of further alienating newcomers to the language who have a misconception that its too hard. > > Admittedly, I am not well informed of the state of GHC 8.0 development and haven't had time to fully look into the situation. I am very interested to see where this conversation and the default complexity of Haskell goes. > > -- > Kyle > > > On Fri, Feb 5, 2016 at 8:26 AM, Tom Ellis wrote: > On Fri, Feb 05, 2016 at 05:25:15PM +0100, Johannes Waldmann wrote: > > > What's changed? > > > > I was referring to a discussion on ghc-devs, see > > https://mail.haskell.org/pipermail/ghc-devs/2016-February/011268.html > > and mixed up addresses when replying. > > I'm glad you did, because this is the first I've heard of it! > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Fri Feb 5 19:05:30 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Fri, 5 Feb 2016 13:05:30 -0600 Subject: [Haskell-cafe] New type of ($) operator in GHC 8.0 is problematic In-Reply-To: <6B40AE7F-84DE-48A2-83FF-1940786CFC1F@cis.upenn.edu> References: <56B4CA58.4050101@htwk-leipzig.de> <56B4CCEB.5060406@htwk-leipzig.de> <20160205162651.GA28854@weber> <6B40AE7F-84DE-48A2-83FF-1940786CFC1F@cis.upenn.edu> Message-ID: Changing the name doesn't fix the issue. The issue is the noise and the referent, not the referrer. There's a habit of over-focusing on names in programming communities. I think it'd be a mistake to do that here and risk missing the point. You can make all of the keywords in the Java example salient early on, but you cannot make the implementation details you're exposing in the type of ($) relevant unless they already have a year or two of Haskell under their belts. Listing out the keywords: 1. public 2. class 3. (class name) 4. static 5. void 6. (method name) 7. (method arguments) Explaining public, class, static, and void usually happens pretty soon after the basics in a Java course. Importantly, they're things you _need_ to know to get things done properly in Java. The same is not true of what is mentioned in the type of ($). The implicit prenex form and forall are irrelevant for learners until they get to Rank2/RankN which is very much beyond, "I am learning Haskell" and into, "I am designing an API in Haskell for other people to use". * vs. # is something many working and hobbyist Haskellers I've known will scarcely know anything about. There is a big difference, to my mind, between what is being exposed here in Java versus what is being exposed in the type ($). Consider that the boxed/unboxed distinction exists in Java but needn't come up in any beginner tutorials. >Types of kind * have values represented by pointers. This is the vast majority of data in Haskell, because almost everything in Haskell is boxed. We can't assume Haskell learners know what pointers are. This, again, creates unnecessary noise for learners by forcing exposure to things that are irrelevant for a very long time. On Fri, Feb 5, 2016 at 12:13 PM, Richard Eisenberg wrote: > Perhaps it will aid the discussion to see that the type of ($) will, for > better or worse, be changing again before 8.0. > > The problem is described in GHC ticket #11471. The details of "why" aren't > all that important for this discussion, but the resolution might be. The > new (hopefully final!) type of ($) will be: > > > ($) :: forall (r :: RuntimeRep) (a :: *) (b :: TYPE r). (a -> b) -> a -> > b > > Once again, it's easy enough to tweak the pretty-printer to hide the > complexity. But perhaps it's not necessary. The difference as far as this > conversation is concerned is that Levity has been renamed to RuntimeRep. I > think this is an improvement, because now it's not terribly hard to explain: > > --- > 1. Types of kind * have values represented by pointers. This is the vast > majority of data in Haskell, because almost everything in Haskell is boxed. > 2. But sometimes, we don't care how a value is represented. In this case, > we can be polymorphic in the choice of representation, just like `length` > is polymorphic in the choice of list element type. > 3. ($) works with functions whose result can have any representation, as > succinctly stated in the type. Note that the argument to the function must > be boxed, however, because the implementation of ($) must store and pass > the argument. It doesn't care at all about the result, though, allowing for > representation-polymorphism. > > In aid of this explanation, we can relate this all to Java. The reference > types in Java (e.g., Object, int[], Boolean) are all like types of kind *. > The primitive types in Java (int, boolean, char) do not have kind *. Java > allows type abstraction (that is, generics) only over the types of kind *. > Haskell is more general, allowing abstraction over primitive types via > representation polymorphism. > --- > > Could this all be explained to a novice programmer? That would be a > struggle. But it could indeed be explained to an intermediate programmer in > another language just learning Haskell. > > For point of comparison, Java is widely used as a teaching language. And > yet one of the simplest programs is > > public class HelloWorld > { > public static void main(String[] args) > { > System.out.println("Hello, world!"); > } > } > > When I taught Java (I taught high-school full time for 8 years), I would > start with something similar to this and have to tell everyone to ignore > 90% of what was written. My course never even got to arrays and `static`! > That was painful, but everyone survived. This is just to point out that > Haskell isn't the only language with this problem. Not to say we shouldn't > try to improve! > > We're in a bit of a bind in all this. We really need the fancy type for > ($) so that it can be used in all situations where it is used currently. > The old type for ($) was just a plain old lie. Now, at least, we're not > lying. So, do we 1) lie, 2) allow the language to grow, or 3) avoid certain > growth because it affects how easy the language is to learn? I don't really > think anyone is advocating for (3) exactly, but it's hard to have (2) and > not make things more complicated -- unless we have a beginners' mode or > other features in, say, GHCi that aid learning. As I've said, I'm in full > favor of adding these features. > > Richard > > On Feb 5, 2016, at 12:55 PM, Kyle Hanson wrote: > > I am also happy the discussion was posted here. Although I don't teach > Haskell professionally, one of the things I loved to do was show people how > simple Haskell really was by inspecting types and slowly putting the puzzle > pieces together. > > Summary of the problem for others: > > From *Takenobu Tani* > > Before ghc7.8: > > Prelude> :t foldr > foldr :: (a -> b -> b) -> b -> [a] -> b > > Prelude> :t ($) > ($) :: (a -> b) -> a -> b > > Beginners should only understand about following: > > * type variable (polymorphism) > > > After ghc8.0: > > Prelude> :t foldr > foldr :: Foldable t => (a -> b -> b) -> b -> t a -> b > > Prelude> :t ($) > ($) > :: forall (w :: GHC.Types.Levity) a (b :: TYPE w). > (a -> b) -> a -> b > > > > With this change it looks like I will no longer be able to keep `$` in my > toolbox since telling a beginner its "magic" goes against what I believe > Haskell is good at, being well defined and easy to understand (Not well > defined in terms of Types but well defined in terms of ability to precisely > and concisely explain and define whats going on). > > It looks like where the discussion is going is to have these types show by > default but eventually have an Alternative prelude for beginners. > > From *Richard Eisenberg:* > > - It's interesting that the solution to the two problems Takenobu pulls out below (but others have hinted at in this thread) is by having an alternate Prelude for beginners. I believe that having an alternate beginners' Prelude is becoming essential. I know I'm not the first one to suggest this, but a great many issues that teachers of Haskell have raised with me and posts on this and other lists would be solved by an alternate Prelude for beginners. > > I don't like the idea of fragmenting Haskell into "beginners" and > "advanced" versions. Its hard enough to get people to believe Haskell is > easy. If they see that they aren't using the "real" prelude, Haskell will > still be this magic black box that is too abstract and difficult to > understand. If they have to use a "dumbed down" version of Haskell to > learn, its not as compelling. > > There is something powerful about using the same idiomatic tools as the > "big boys" and have the tools still be able to be easy to understand.... by > default. Adding complexity to the default Haskell runs the risk of further > alienating newcomers to the language who have a misconception that its too > hard. > > Admittedly, I am not well informed of the state of GHC 8.0 development and > haven't had time to fully look into the situation. I am very interested to > see where this conversation and the default complexity of Haskell goes. > > -- > Kyle > > > On Fri, Feb 5, 2016 at 8:26 AM, Tom Ellis < > tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > >> On Fri, Feb 05, 2016 at 05:25:15PM +0100, Johannes Waldmann wrote: >> > > What's changed? >> > >> > I was referring to a discussion on ghc-devs, see >> > https://mail.haskell.org/pipermail/ghc-devs/2016-February/011268.html >> > and mixed up addresses when replying. >> >> I'm glad you did, because this is the first I've heard of it! >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > _______________________________________________ > 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 cma at bitemyapp.com Fri Feb 5 19:16:56 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Fri, 5 Feb 2016 13:16:56 -0600 Subject: [Haskell-cafe] New type of ($) operator in GHC 8.0 is problematic In-Reply-To: References: <56B4CA58.4050101@htwk-leipzig.de> <56B4CCEB.5060406@htwk-leipzig.de> <20160205162651.GA28854@weber> <6B40AE7F-84DE-48A2-83FF-1940786CFC1F@cis.upenn.edu> Message-ID: I just showed the type of ($) to my boss in our company chat who has been using Haskell for 14 years. He'd played with Haskell prior to that, but 14 years ago is when he started postgrad and teaching Haskell. Here's what he said: >...what? >what does that do? He's been using Haskell in production for the last 5 years as well, I think. Please simplify the type unless a pragma specific to levity is turned on. As it happens, I like the name levity better than runtimerep, but neither solve any pedagogical issues. YMMV. On Fri, Feb 5, 2016 at 1:12 PM, Bardur Arantsson wrote: > On 02/05/2016 08:05 PM, Christopher Allen wrote: > > Changing the name doesn't fix the issue. The issue is the noise and the > > referent, not the referrer. There's a habit of over-focusing on names in > > programming communities. I think it'd be a mistake to do that here and > risk > > missing the point. > > > > I think you're being a bit harsh, but I *do* think you're essentially > right. Beginners will have no idea what most the that means, so... *yes* > the type *will* need to be simplified for display purposes. (Unless, of > course, you opt-in to full signatures.) > > Regards, > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Chris Allen Currently working on http://haskellbook.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at izbicki.me Fri Feb 5 23:21:00 2016 From: mike at izbicki.me (Mike Izbicki) Date: Fri, 5 Feb 2016 15:21:00 -0800 Subject: [Haskell-cafe] New type of ($) operator in GHC 8.0 is problematic In-Reply-To: <6B40AE7F-84DE-48A2-83FF-1940786CFC1F@cis.upenn.edu> References: <56B4CA58.4050101@htwk-leipzig.de> <56B4CCEB.5060406@htwk-leipzig.de> <20160205162651.GA28854@weber> <6B40AE7F-84DE-48A2-83FF-1940786CFC1F@cis.upenn.edu> Message-ID: > We're in a bit of a bind in all this. We really need the fancy type for ($) > so that it can be used in all situations where it is used currently. The old > type for ($) was just a plain old lie. Now, at least, we're not lying. So, > do we 1) lie, 2) allow the language to grow, or 3) avoid certain growth > because it affects how easy the language is to learn? I don't really think > anyone is advocating for (3) exactly, but it's hard to have (2) and not make > things more complicated -- unless we have a beginners' mode or other > features in, say, GHCi that aid learning. As I've said, I'm in full favor of > adding these features. The old type for ($) is only a lie when the MagicHash extension is turned on. Otherwise, it is not a lie. I think the best solution is to pretty print the type depending on what language pragmas are in use. In GHCI, this would be trivial. The much harder case is haddock documentation. I think a good way around this would be an eventual patch to haddock that allows the user to select which extensions they want to use when browsing documentation. There's a lot of usability issues that would need to be resolved with this still, but it reduces this technical discussion we're having down to a design discussion. It also nicely lets the user specify the level of difficulty they want their prelude to be without causing incompatibilty with users who want a different level of prelude. From george.colpitts at gmail.com Fri Feb 5 23:30:12 2016 From: george.colpitts at gmail.com (George Colpitts) Date: Fri, 5 Feb 2016 19:30:12 -0400 Subject: [Haskell-cafe] New type of ($) operator in GHC 8.0 is problematic In-Reply-To: References: <56B4CA58.4050101@htwk-leipzig.de> <56B4CCEB.5060406@htwk-leipzig.de> <20160205162651.GA28854@weber> <6B40AE7F-84DE-48A2-83FF-1940786CFC1F@cis.upenn.edu> Message-ID: +1 for Christopher's email Richard, I disagree with "But it could indeed be explained to an intermediate programmer in another language just learning Haskell." Your explanation is good but it assumes you have already explained "types of kind *" and the boxed vs unboxed distinction. Admittedly the latter should be understood by most Java programmers but I doubt that intermediate programmers in other languages do. If I did have to explain "$" I would say, for now think of it in terms of it's pre 8.0 type. Alternatively avoid mentioning "$" to beginners. I don't believe it is in Hutton's book or any of Bird's although I might be wrong. Most intermediate programmers in another language struggle a lot with learning monads, witness all the monad tutorials. Absorbing monads is central, there is a lot that has to be explained before that. Minimizing that material would be a good thing. I have mixed feelings about a beginner's prelude best summarized by saying the proposed beginner's prelude should be the standard prelude and the current one should be an advanced prelude. If we have a beginner's prelude I feel we are saying that this is a hard to understand research language and we hope that someday you have enough education, energy and tenacity to get to the point where you understand it. If we do it the other way we are saying you have what you need but if you want more there is lots! On Fri, Feb 5, 2016 at 3:05 PM, Christopher Allen wrote: > Changing the name doesn't fix the issue. The issue is the noise and the > referent, not the referrer. There's a habit of over-focusing on names in > programming communities. I think it'd be a mistake to do that here and risk > missing the point. > > You can make all of the keywords in the Java example salient early on, but > you cannot make the implementation details you're exposing in the type of > ($) relevant unless they already have a year or two of Haskell under their > belts. Listing out the keywords: > > 1. public > > 2. class > > 3. (class name) > > 4. static > > 5. void > > 6. (method name) > > 7. (method arguments) > > Explaining public, class, static, and void usually happens pretty soon > after the basics in a Java course. Importantly, they're things you _need_ > to know to get things done properly in Java. The same is not true of what > is mentioned in the type of ($). > > The implicit prenex form and forall are irrelevant for learners until they > get to Rank2/RankN which is very much beyond, "I am learning Haskell" and > into, "I am designing an API in Haskell for other people to use". * vs. # > is something many working and hobbyist Haskellers I've known will scarcely > know anything about. > > There is a big difference, to my mind, between what is being exposed here > in Java versus what is being exposed in the type ($). Consider that the > boxed/unboxed distinction exists in Java but needn't come up in any > beginner tutorials. > > >Types of kind * have values represented by pointers. This is the vast > majority of data in Haskell, because almost everything in Haskell is boxed. > > We can't assume Haskell learners know what pointers are. This, again, > creates unnecessary noise for learners by forcing exposure to things that > are irrelevant for a very long time. > > > On Fri, Feb 5, 2016 at 12:13 PM, Richard Eisenberg > wrote: > >> Perhaps it will aid the discussion to see that the type of ($) will, for >> better or worse, be changing again before 8.0. >> >> The problem is described in GHC ticket #11471. The details of "why" >> aren't all that important for this discussion, but the resolution might be. >> The new (hopefully final!) type of ($) will be: >> >> > ($) :: forall (r :: RuntimeRep) (a :: *) (b :: TYPE r). (a -> b) -> a >> -> b >> >> Once again, it's easy enough to tweak the pretty-printer to hide the >> complexity. But perhaps it's not necessary. The difference as far as this >> conversation is concerned is that Levity has been renamed to RuntimeRep. I >> think this is an improvement, because now it's not terribly hard to explain: >> >> --- >> 1. Types of kind * have values represented by pointers. This is the vast >> majority of data in Haskell, because almost everything in Haskell is boxed. >> 2. But sometimes, we don't care how a value is represented. In this case, >> we can be polymorphic in the choice of representation, just like `length` >> is polymorphic in the choice of list element type. >> 3. ($) works with functions whose result can have any representation, as >> succinctly stated in the type. Note that the argument to the function must >> be boxed, however, because the implementation of ($) must store and pass >> the argument. It doesn't care at all about the result, though, allowing for >> representation-polymorphism. >> >> In aid of this explanation, we can relate this all to Java. The reference >> types in Java (e.g., Object, int[], Boolean) are all like types of kind *. >> The primitive types in Java (int, boolean, char) do not have kind *. Java >> allows type abstraction (that is, generics) only over the types of kind *. >> Haskell is more general, allowing abstraction over primitive types via >> representation polymorphism. >> --- >> >> Could this all be explained to a novice programmer? That would be a >> struggle. But it could indeed be explained to an intermediate programmer in >> another language just learning Haskell. >> >> For point of comparison, Java is widely used as a teaching language. And >> yet one of the simplest programs is >> >> public class HelloWorld >> { >> public static void main(String[] args) >> { >> System.out.println("Hello, world!"); >> } >> } >> >> When I taught Java (I taught high-school full time for 8 years), I would >> start with something similar to this and have to tell everyone to ignore >> 90% of what was written. My course never even got to arrays and `static`! >> That was painful, but everyone survived. This is just to point out that >> Haskell isn't the only language with this problem. Not to say we shouldn't >> try to improve! >> >> We're in a bit of a bind in all this. We really need the fancy type for >> ($) so that it can be used in all situations where it is used currently. >> The old type for ($) was just a plain old lie. Now, at least, we're not >> lying. So, do we 1) lie, 2) allow the language to grow, or 3) avoid certain >> growth because it affects how easy the language is to learn? I don't really >> think anyone is advocating for (3) exactly, but it's hard to have (2) and >> not make things more complicated -- unless we have a beginners' mode or >> other features in, say, GHCi that aid learning. As I've said, I'm in full >> favor of adding these features. >> >> Richard >> >> On Feb 5, 2016, at 12:55 PM, Kyle Hanson wrote: >> >> I am also happy the discussion was posted here. Although I don't teach >> Haskell professionally, one of the things I loved to do was show people how >> simple Haskell really was by inspecting types and slowly putting the puzzle >> pieces together. >> >> Summary of the problem for others: >> >> From *Takenobu Tani* >> >> Before ghc7.8: >> >> Prelude> :t foldr >> foldr :: (a -> b -> b) -> b -> [a] -> b >> >> Prelude> :t ($) >> ($) :: (a -> b) -> a -> b >> >> Beginners should only understand about following: >> >> * type variable (polymorphism) >> >> >> After ghc8.0: >> >> Prelude> :t foldr >> foldr :: Foldable t => (a -> b -> b) -> b -> t a -> b >> >> Prelude> :t ($) >> ($) >> :: forall (w :: GHC.Types.Levity) a (b :: TYPE w). >> (a -> b) -> a -> b >> >> >> >> With this change it looks like I will no longer be able to keep `$` in my >> toolbox since telling a beginner its "magic" goes against what I believe >> Haskell is good at, being well defined and easy to understand (Not well >> defined in terms of Types but well defined in terms of ability to precisely >> and concisely explain and define whats going on). >> >> It looks like where the discussion is going is to have these types show >> by default but eventually have an Alternative prelude for beginners. >> >> From *Richard Eisenberg:* >> >> - It's interesting that the solution to the two problems Takenobu pulls out below (but others have hinted at in this thread) is by having an alternate Prelude for beginners. I believe that having an alternate beginners' Prelude is becoming essential. I know I'm not the first one to suggest this, but a great many issues that teachers of Haskell have raised with me and posts on this and other lists would be solved by an alternate Prelude for beginners. >> >> I don't like the idea of fragmenting Haskell into "beginners" and >> "advanced" versions. Its hard enough to get people to believe Haskell is >> easy. If they see that they aren't using the "real" prelude, Haskell will >> still be this magic black box that is too abstract and difficult to >> understand. If they have to use a "dumbed down" version of Haskell to >> learn, its not as compelling. >> >> There is something powerful about using the same idiomatic tools as the >> "big boys" and have the tools still be able to be easy to understand.... by >> default. Adding complexity to the default Haskell runs the risk of further >> alienating newcomers to the language who have a misconception that its too >> hard. >> >> Admittedly, I am not well informed of the state of GHC 8.0 development >> and haven't had time to fully look into the situation. I am very interested >> to see where this conversation and the default complexity of Haskell goes. >> >> -- >> Kyle >> >> >> On Fri, Feb 5, 2016 at 8:26 AM, Tom Ellis < >> tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: >> >>> On Fri, Feb 05, 2016 at 05:25:15PM +0100, Johannes Waldmann wrote: >>> > > What's changed? >>> > >>> > I was referring to a discussion on ghc-devs, see >>> > https://mail.haskell.org/pipermail/ghc-devs/2016-February/011268.html >>> > and mixed up addresses when replying. >>> >>> I'm glad you did, because this is the first I've heard of it! >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> >> >> _______________________________________________ >> 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 > > _______________________________________________ > 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 Sat Feb 6 00:09:44 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 5 Feb 2016 19:09:44 -0500 Subject: Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic) In-Reply-To: References: <56B4CA58.4050101@htwk-leipzig.de> <56B4CCEB.5060406@htwk-leipzig.de> <20160205162651.GA28854@weber> <6B40AE7F-84DE-48A2-83FF-1940786CFC1F@cis.upenn.edu> Message-ID: It may come as a surprise to many of you that I, too, am very worried about Haskell becoming inaccessible to newcomers. If we can't induct new people into our ranks, we will die. It is for this reason that I have always been unhappy with the FTP. But that ship has sailed. I fully agree with George's suggestion below that the default Prelude should be the beginner's Prelude. I believe I have argued this stance in the past, but louder voices prevailed. Perhaps I was wrong in branding: we should have a proper Prelude as the default, and make available a super whiz-bang advanced Prelude as well. I'm never very good about branding. I'd lend strong support to someone who articulates a concrete move in this direction, but I don't have the bandwidth to spearhead it myself. Despite the various arguments saying that the bits in Java are easier to understand than the bits in ($), I'm quite unconvinced. (Particularly about `static`. Even `class` is hard for true beginners.) And the boxed/unboxed distinction does come up early in Java: just try to write an ArrayList and now you need to know about boxed types and unboxed ones. Chris's point that "it's not about the name" is valid. The Levity --> RuntimeRep change is not about the name, but about the functionality. Levity distinguished only between lifted and unlifted; RuntimeRep distinguishes between boxed/lifted, boxed/unlifted, and all the unboxed types with their different widths. I'm just clarifying that it's not simply a cosmetic name-change. The old type of ($) was always a lie. -XMagicHash just changes the parser, allowing the # suffix. It is only by convention that most (all?) unlifted things end in #. The old type of ($) was perhaps a harmless lie, but a lie nonetheless. Are we comfortable with lying? (Believe me, I'm not trying to impose some moral dimension to simplifying output!) In my mind, lying about types like this is in the same space as having a beginner's Prelude. And people will constantly discover that we're lying and get very confused. Having a whole host of flags that tell GHC to lie less is somewhat like having two versions of the language... only the differences manifest only in output instead of input. If we are comfortable with lying in this way: as I've offered, I can hide the type of ($) (and other representation-polymorphic things) behind a flag. Easy to do. Another great question that has come up is about Haddock output (Hackage). I think Haddock needs to add a facility where library authors can include specializations of an overly general type. This can be done in commentary, but it's not as prominent. Such a new feature would address the ($) problem, as ($) :: forall (a :: *) (b :: *). (a -> b) -> a -> b is a specialization of its real type. It would also help a great deal with FTP-related generalizations. I also want to respond directly to Kyle's comments: > I think its important to identify who you want your "customers" to be. If you only want the most advanced type theorists to use the language, that is perfectly fine, but what you lose are thousands of developers that can benefit the Haskell community without having to know advanced Typing. Rest assured, I want my "customers" to be everyone who wants to program. I've volunteered to teach a bit of Haskell to high schoolers, and I'd love a shot at a course where I teach it to people who have never programmed. > > Needing a "Beginners" mode in a language is *not* a feature, its a fundamental design flaw. It shows that the language was not sufficiently thought out and designed for everyone. On an intuitive level, this rings true for me. But when I think about the details, I'm less convinced. For example, take Scratch (scratch.mit.edu), which is wonderfully easy to learn and gives kids (and adults!) a great deal of fun. Yet it's painful to use when you know more. And the Racket folks have invested a lot of time in coming up with a curriculum to go with their language, and they explicitly have expertise levels. Needing these levels may just be part of the game. So, rest assured, I remain very receptive to these concerns. And I'd love concrete help in putting them to rest. Richard On Feb 5, 2016, at 6:30 PM, George Colpitts wrote: > +1 for Christopher's email > Richard, I disagree with "But it could indeed be explained to an intermediate programmer in another language just learning Haskell." Your explanation is good but it assumes you have already explained "types of kind *" and the boxed vs unboxed distinction. Admittedly the latter should be understood by most Java programmers but I doubt that intermediate programmers in other languages do. If I did have to explain "$" I would say, for now think of it in terms of it's pre 8.0 type. Alternatively avoid mentioning "$" to beginners. I don't believe it is in Hutton's book or any of Bird's although I might be wrong. > > Most intermediate programmers in another language struggle a lot with learning monads, witness all the monad tutorials. Absorbing monads is central, there is a lot that has to be explained before that. Minimizing that material would be a good thing. > > I have mixed feelings about a beginner's prelude best summarized by saying the proposed beginner's prelude should be the standard prelude and the current one should be an advanced prelude. If we have a beginner's prelude I feel we are saying that this is a hard to understand research language and we hope that someday you have enough education, energy and tenacity to get to the point where you understand it. If we do it the other way we are saying you have what you need but if you want more there is lots! > > On Fri, Feb 5, 2016 at 3:05 PM, Christopher Allen wrote: > Changing the name doesn't fix the issue. The issue is the noise and the referent, not the referrer. There's a habit of over-focusing on names in programming communities. I think it'd be a mistake to do that here and risk missing the point. > > You can make all of the keywords in the Java example salient early on, but you cannot make the implementation details you're exposing in the type of ($) relevant unless they already have a year or two of Haskell under their belts. Listing out the keywords: > > 1. public > > 2. class > > 3. (class name) > > 4. static > > 5. void > > 6. (method name) > > 7. (method arguments) > > Explaining public, class, static, and void usually happens pretty soon after the basics in a Java course. Importantly, they're things you _need_ to know to get things done properly in Java. The same is not true of what is mentioned in the type of ($). > > The implicit prenex form and forall are irrelevant for learners until they get to Rank2/RankN which is very much beyond, "I am learning Haskell" and into, "I am designing an API in Haskell for other people to use". * vs. # is something many working and hobbyist Haskellers I've known will scarcely know anything about. > > There is a big difference, to my mind, between what is being exposed here in Java versus what is being exposed in the type ($). Consider that the boxed/unboxed distinction exists in Java but needn't come up in any beginner tutorials. > > >Types of kind * have values represented by pointers. This is the vast majority of data in Haskell, because almost everything in Haskell is boxed. > > We can't assume Haskell learners know what pointers are. This, again, creates unnecessary noise for learners by forcing exposure to things that are irrelevant for a very long time. > > > On Fri, Feb 5, 2016 at 12:13 PM, Richard Eisenberg wrote: > Perhaps it will aid the discussion to see that the type of ($) will, for better or worse, be changing again before 8.0. > > The problem is described in GHC ticket #11471. The details of "why" aren't all that important for this discussion, but the resolution might be. The new (hopefully final!) type of ($) will be: > > > ($) :: forall (r :: RuntimeRep) (a :: *) (b :: TYPE r). (a -> b) -> a -> b > > Once again, it's easy enough to tweak the pretty-printer to hide the complexity. But perhaps it's not necessary. The difference as far as this conversation is concerned is that Levity has been renamed to RuntimeRep. I think this is an improvement, because now it's not terribly hard to explain: > > --- > 1. Types of kind * have values represented by pointers. This is the vast majority of data in Haskell, because almost everything in Haskell is boxed. > 2. But sometimes, we don't care how a value is represented. In this case, we can be polymorphic in the choice of representation, just like `length` is polymorphic in the choice of list element type. > 3. ($) works with functions whose result can have any representation, as succinctly stated in the type. Note that the argument to the function must be boxed, however, because the implementation of ($) must store and pass the argument. It doesn't care at all about the result, though, allowing for representation-polymorphism. > > In aid of this explanation, we can relate this all to Java. The reference types in Java (e.g., Object, int[], Boolean) are all like types of kind *. The primitive types in Java (int, boolean, char) do not have kind *. Java allows type abstraction (that is, generics) only over the types of kind *. Haskell is more general, allowing abstraction over primitive types via representation polymorphism. > --- > > Could this all be explained to a novice programmer? That would be a struggle. But it could indeed be explained to an intermediate programmer in another language just learning Haskell. > > For point of comparison, Java is widely used as a teaching language. And yet one of the simplest programs is > > public class HelloWorld > { > public static void main(String[] args) > { > System.out.println("Hello, world!"); > } > } > > When I taught Java (I taught high-school full time for 8 years), I would start with something similar to this and have to tell everyone to ignore 90% of what was written. My course never even got to arrays and `static`! That was painful, but everyone survived. This is just to point out that Haskell isn't the only language with this problem. Not to say we shouldn't try to improve! > > We're in a bit of a bind in all this. We really need the fancy type for ($) so that it can be used in all situations where it is used currently. The old type for ($) was just a plain old lie. Now, at least, we're not lying. So, do we 1) lie, 2) allow the language to grow, or 3) avoid certain growth because it affects how easy the language is to learn? I don't really think anyone is advocating for (3) exactly, but it's hard to have (2) and not make things more complicated -- unless we have a beginners' mode or other features in, say, GHCi that aid learning. As I've said, I'm in full favor of adding these features. > > Richard > > On Feb 5, 2016, at 12:55 PM, Kyle Hanson wrote: > >> I am also happy the discussion was posted here. Although I don't teach Haskell professionally, one of the things I loved to do was show people how simple Haskell really was by inspecting types and slowly putting the puzzle pieces together. >> >> Summary of the problem for others: >> From Takenobu Tani >> Before ghc7.8: >> >> Prelude> :t foldr >> foldr :: (a -> b -> b) -> b -> [a] -> b >> >> Prelude> :t ($) >> ($) :: (a -> b) -> a -> b >> >> Beginners should only understand about following: >> >> * type variable (polymorphism) >> >> >> After ghc8.0: >> >> Prelude> :t foldr >> foldr :: Foldable t => (a -> b -> b) -> b -> t a -> b >> >> Prelude> :t ($) >> ($) >> :: forall (w :: GHC.Types.Levity) a (b :: TYPE w). >> (a -> b) -> a -> b >> >> >> With this change it looks like I will no longer be able to keep `$` in my toolbox since telling a beginner its "magic" goes against what I believe Haskell is good at, being well defined and easy to understand (Not well defined in terms of Types but well defined in terms of ability to precisely and concisely explain and define whats going on). >> >> It looks like where the discussion is going is to have these types show by default but eventually have an Alternative prelude for beginners. >> >> From Richard Eisenberg: >> - It's interesting that the solution to the two problems Takenobu pulls out below (but others have hinted at in this thread) is by having an alternate Prelude for beginners. I believe that having an alternate beginners' Prelude is becoming essential. I know I'm not the first one to suggest this, but a great many issues that teachers of Haskell have raised with me and posts on this and other lists would be solved by an alternate Prelude for beginners. >> I don't like the idea of fragmenting Haskell into "beginners" and "advanced" versions. Its hard enough to get people to believe Haskell is easy. If they see that they aren't using the "real" prelude, Haskell will still be this magic black box that is too abstract and difficult to understand. If they have to use a "dumbed down" version of Haskell to learn, its not as compelling. >> >> There is something powerful about using the same idiomatic tools as the "big boys" and have the tools still be able to be easy to understand.... by default. Adding complexity to the default Haskell runs the risk of further alienating newcomers to the language who have a misconception that its too hard. >> >> Admittedly, I am not well informed of the state of GHC 8.0 development and haven't had time to fully look into the situation. I am very interested to see where this conversation and the default complexity of Haskell goes. >> >> -- >> Kyle >> >> >> On Fri, Feb 5, 2016 at 8:26 AM, Tom Ellis wrote: >> On Fri, Feb 05, 2016 at 05:25:15PM +0100, Johannes Waldmann wrote: >> > > What's changed? >> > >> > I was referring to a discussion on ghc-devs, see >> > https://mail.haskell.org/pipermail/ghc-devs/2016-February/011268.html >> > and mixed up addresses when replying. >> >> I'm glad you did, because this is the first I've heard of it! >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > _______________________________________________ > 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 > > _______________________________________________ > 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 takenobu.hs at gmail.com Sat Feb 6 00:28:58 2016 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Sat, 6 Feb 2016 09:28:58 +0900 Subject: Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic) In-Reply-To: References: <56B4CA58.4050101@htwk-leipzig.de> <56B4CCEB.5060406@htwk-leipzig.de> <20160205162651.GA28854@weber> <6B40AE7F-84DE-48A2-83FF-1940786CFC1F@cis.upenn.edu> Message-ID: Hi, I tried to draw informal illustrations about Foldable signatures for beginners [1]. I'll also try to draw simple illustrations about new ($). Of course I like Haskell's beautiful abstraction :) Thank you for your great efforts. [1] http://takenobu-hs.github.io/downloads/type_introduction_illustrated.pdf Regards, Takenobu 2016-02-06 9:09 GMT+09:00 Richard Eisenberg : > It may come as a surprise to many of you that I, too, am very worried > about Haskell becoming inaccessible to newcomers. If we can't induct new > people into our ranks, we will die. It is for this reason that I have > always been unhappy with the FTP. But that ship has sailed. > > I fully agree with George's suggestion below that the default Prelude > should be the beginner's Prelude. I believe I have argued this stance in > the past, but louder voices prevailed. Perhaps I was wrong in branding: we > should have a proper Prelude as the default, and make available a super > whiz-bang advanced Prelude as well. I'm never very good about branding. I'd > lend strong support to someone who articulates a concrete move in this > direction, but I don't have the bandwidth to spearhead it myself. > > Despite the various arguments saying that the bits in Java are easier to > understand than the bits in ($), I'm quite unconvinced. (Particularly about > `static`. Even `class` is hard for true beginners.) And the boxed/unboxed > distinction does come up early in Java: just try to write an ArrayList > and now you need to know about boxed types and unboxed ones. > > Chris's point that "it's not about the name" is valid. The Levity --> > RuntimeRep change is not about the name, but about the functionality. > Levity distinguished only between lifted and unlifted; RuntimeRep > distinguishes between boxed/lifted, boxed/unlifted, and all the unboxed > types with their different widths. I'm just clarifying that it's not simply > a cosmetic name-change. > > The old type of ($) was always a lie. -XMagicHash just changes the parser, > allowing the # suffix. It is only by convention that most (all?) unlifted > things end in #. The old type of ($) was perhaps a harmless lie, but a lie > nonetheless. > > Are we comfortable with lying? (Believe me, I'm not trying to impose some > moral dimension to simplifying output!) In my mind, lying about types like > this is in the same space as having a beginner's Prelude. And people will > constantly discover that we're lying and get very confused. Having a whole > host of flags that tell GHC to lie less is somewhat like having two > versions of the language... only the differences manifest only in output > instead of input. > > If we are comfortable with lying in this way: as I've offered, I can hide > the type of ($) (and other representation-polymorphic things) behind a > flag. Easy to do. > > Another great question that has come up is about Haddock output (Hackage). > I think Haddock needs to add a facility where library authors can include > specializations of an overly general type. This can be done in commentary, > but it's not as prominent. Such a new feature would address the ($) > problem, as ($) :: forall (a :: *) (b :: *). (a -> b) -> a -> b is a > specialization of its real type. It would also help a great deal with > FTP-related generalizations. > > I also want to respond directly to Kyle's comments: > > I think its important to identify who you want your "customers" to be. If > you only want the most advanced type theorists to use the language, that is > perfectly fine, but what you lose are thousands of developers that can > benefit the Haskell community without having to know advanced Typing. > > > Rest assured, I want my "customers" to be everyone who wants to program. > I've volunteered to teach a bit of Haskell to high schoolers, and I'd love > a shot at a course where I teach it to people who have never programmed. > > > Needing a "Beginners" mode in a language is *not* a feature, its a > fundamental design flaw. It shows that the language was not sufficiently > thought out and designed for everyone. > > > On an intuitive level, this rings true for me. But when I think about the > details, I'm less convinced. For example, take Scratch (scratch.mit.edu), > which is wonderfully easy to learn and gives kids (and adults!) a great > deal of fun. Yet it's painful to use when you know more. And the Racket > folks have invested a lot of time in coming up with a curriculum to go with > their language, and they explicitly have expertise levels. Needing these > levels may just be part of the game. > > So, rest assured, I remain very receptive to these concerns. And I'd love > concrete help in putting them to rest. > > Richard > > > On Feb 5, 2016, at 6:30 PM, George Colpitts > wrote: > > +1 for Christopher's email > Richard, I disagree with "But it could indeed be explained to an > intermediate programmer in another language just learning Haskell." Your > explanation is good but it assumes you have already explained "types of > kind *" and the boxed vs unboxed distinction. Admittedly the latter should > be understood by most Java programmers but I doubt that intermediate > programmers in other languages do. If I did have to explain "$" I would > say, for now think of it in terms of it's pre 8.0 type. Alternatively avoid > mentioning "$" to beginners. I don't believe it is in Hutton's book or any > of Bird's although I might be wrong. > > Most intermediate programmers in another language struggle a lot with > learning monads, witness all the monad tutorials. Absorbing monads is > central, there is a lot that has to be explained before that. Minimizing > that material would be a good thing. > > I have mixed feelings about a beginner's prelude best summarized by saying > the proposed beginner's prelude should be the standard prelude and the > current one should be an advanced prelude. If we have a beginner's prelude > I feel we are saying that this is a hard to understand research language > and we hope that someday you have enough education, energy and tenacity to > get to the point where you understand it. If we do it the other way we are > saying you have what you need but if you want more there is lots! > > On Fri, Feb 5, 2016 at 3:05 PM, Christopher Allen > wrote: > >> Changing the name doesn't fix the issue. The issue is the noise and the >> referent, not the referrer. There's a habit of over-focusing on names in >> programming communities. I think it'd be a mistake to do that here and risk >> missing the point. >> >> You can make all of the keywords in the Java example salient early on, >> but you cannot make the implementation details you're exposing in the type >> of ($) relevant unless they already have a year or two of Haskell under >> their belts. Listing out the keywords: >> >> 1. public >> >> 2. class >> >> 3. (class name) >> >> 4. static >> >> 5. void >> >> 6. (method name) >> >> 7. (method arguments) >> >> Explaining public, class, static, and void usually happens pretty soon >> after the basics in a Java course. Importantly, they're things you _need_ >> to know to get things done properly in Java. The same is not true of what >> is mentioned in the type of ($). >> >> The implicit prenex form and forall are irrelevant for learners until >> they get to Rank2/RankN which is very much beyond, "I am learning Haskell" >> and into, "I am designing an API in Haskell for other people to use". * vs. >> # is something many working and hobbyist Haskellers I've known will >> scarcely know anything about. >> >> There is a big difference, to my mind, between what is being exposed here >> in Java versus what is being exposed in the type ($). Consider that the >> boxed/unboxed distinction exists in Java but needn't come up in any >> beginner tutorials. >> >> >Types of kind * have values represented by pointers. This is the vast >> majority of data in Haskell, because almost everything in Haskell is boxed. >> >> We can't assume Haskell learners know what pointers are. This, again, >> creates unnecessary noise for learners by forcing exposure to things that >> are irrelevant for a very long time. >> >> >> On Fri, Feb 5, 2016 at 12:13 PM, Richard Eisenberg >> wrote: >> >>> Perhaps it will aid the discussion to see that the type of ($) will, for >>> better or worse, be changing again before 8.0. >>> >>> The problem is described in GHC ticket #11471. The details of "why" >>> aren't all that important for this discussion, but the resolution might be. >>> The new (hopefully final!) type of ($) will be: >>> >>> > ($) :: forall (r :: RuntimeRep) (a :: *) (b :: TYPE r). (a -> b) -> a >>> -> b >>> >>> Once again, it's easy enough to tweak the pretty-printer to hide the >>> complexity. But perhaps it's not necessary. The difference as far as this >>> conversation is concerned is that Levity has been renamed to RuntimeRep. I >>> think this is an improvement, because now it's not terribly hard to explain: >>> >>> --- >>> 1. Types of kind * have values represented by pointers. This is the vast >>> majority of data in Haskell, because almost everything in Haskell is boxed. >>> 2. But sometimes, we don't care how a value is represented. In this >>> case, we can be polymorphic in the choice of representation, just like >>> `length` is polymorphic in the choice of list element type. >>> 3. ($) works with functions whose result can have any representation, as >>> succinctly stated in the type. Note that the argument to the function must >>> be boxed, however, because the implementation of ($) must store and pass >>> the argument. It doesn't care at all about the result, though, allowing for >>> representation-polymorphism. >>> >>> In aid of this explanation, we can relate this all to Java. The >>> reference types in Java (e.g., Object, int[], Boolean) are all like types >>> of kind *. The primitive types in Java (int, boolean, char) do not have >>> kind *. Java allows type abstraction (that is, generics) only over the >>> types of kind *. Haskell is more general, allowing abstraction over >>> primitive types via representation polymorphism. >>> --- >>> >>> Could this all be explained to a novice programmer? That would be a >>> struggle. But it could indeed be explained to an intermediate programmer in >>> another language just learning Haskell. >>> >>> For point of comparison, Java is widely used as a teaching language. And >>> yet one of the simplest programs is >>> >>> public class HelloWorld >>> { >>> public static void main(String[] args) >>> { >>> System.out.println("Hello, world!"); >>> } >>> } >>> >>> When I taught Java (I taught high-school full time for 8 years), I would >>> start with something similar to this and have to tell everyone to ignore >>> 90% of what was written. My course never even got to arrays and `static`! >>> That was painful, but everyone survived. This is just to point out that >>> Haskell isn't the only language with this problem. Not to say we shouldn't >>> try to improve! >>> >>> We're in a bit of a bind in all this. We really need the fancy type for >>> ($) so that it can be used in all situations where it is used currently. >>> The old type for ($) was just a plain old lie. Now, at least, we're not >>> lying. So, do we 1) lie, 2) allow the language to grow, or 3) avoid certain >>> growth because it affects how easy the language is to learn? I don't really >>> think anyone is advocating for (3) exactly, but it's hard to have (2) and >>> not make things more complicated -- unless we have a beginners' mode or >>> other features in, say, GHCi that aid learning. As I've said, I'm in full >>> favor of adding these features. >>> >>> Richard >>> >>> On Feb 5, 2016, at 12:55 PM, Kyle Hanson wrote: >>> >>> I am also happy the discussion was posted here. Although I don't teach >>> Haskell professionally, one of the things I loved to do was show people how >>> simple Haskell really was by inspecting types and slowly putting the puzzle >>> pieces together. >>> >>> Summary of the problem for others: >>> >>> From *Takenobu Tani* >>> >>> Before ghc7.8: >>> >>> Prelude> :t foldr >>> foldr :: (a -> b -> b) -> b -> [a] -> b >>> >>> Prelude> :t ($) >>> ($) :: (a -> b) -> a -> b >>> >>> Beginners should only understand about following: >>> >>> * type variable (polymorphism) >>> >>> >>> After ghc8.0: >>> >>> Prelude> :t foldr >>> foldr :: Foldable t => (a -> b -> b) -> b -> t a -> b >>> >>> Prelude> :t ($) >>> ($) >>> :: forall (w :: GHC.Types.Levity) a (b :: TYPE w). >>> (a -> b) -> a -> b >>> >>> >>> >>> With this change it looks like I will no longer be able to keep `$` in >>> my toolbox since telling a beginner its "magic" goes against what I believe >>> Haskell is good at, being well defined and easy to understand (Not well >>> defined in terms of Types but well defined in terms of ability to precisely >>> and concisely explain and define whats going on). >>> >>> It looks like where the discussion is going is to have these types show >>> by default but eventually have an Alternative prelude for beginners. >>> >>> From *Richard Eisenberg:* >>> >>> - It's interesting that the solution to the two problems Takenobu pulls out below (but others have hinted at in this thread) is by having an alternate Prelude for beginners. I believe that having an alternate beginners' Prelude is becoming essential. I know I'm not the first one to suggest this, but a great many issues that teachers of Haskell have raised with me and posts on this and other lists would be solved by an alternate Prelude for beginners. >>> >>> I don't like the idea of fragmenting Haskell into "beginners" and >>> "advanced" versions. Its hard enough to get people to believe Haskell is >>> easy. If they see that they aren't using the "real" prelude, Haskell will >>> still be this magic black box that is too abstract and difficult to >>> understand. If they have to use a "dumbed down" version of Haskell to >>> learn, its not as compelling. >>> >>> There is something powerful about using the same idiomatic tools as the >>> "big boys" and have the tools still be able to be easy to understand.... by >>> default. Adding complexity to the default Haskell runs the risk of further >>> alienating newcomers to the language who have a misconception that its too >>> hard. >>> >>> Admittedly, I am not well informed of the state of GHC 8.0 development >>> and haven't had time to fully look into the situation. I am very interested >>> to see where this conversation and the default complexity of Haskell goes. >>> >>> -- >>> Kyle >>> >>> >>> On Fri, Feb 5, 2016 at 8:26 AM, Tom Ellis < >>> tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: >>> >>>> On Fri, Feb 05, 2016 at 05:25:15PM +0100, Johannes Waldmann wrote: >>>> > > What's changed? >>>> > >>>> > I was referring to a discussion on ghc-devs, see >>>> > https://mail.haskell.org/pipermail/ghc-devs/2016-February/011268.html >>>> > and mixed up addresses when replying. >>>> >>>> I'm glad you did, because this is the first I've heard of it! >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Sat Feb 6 01:51:13 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 5 Feb 2016 20:51:13 -0500 Subject: [Haskell-cafe] Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic) In-Reply-To: <56B542AF.4070106@artyom.me> References: <56B4CA58.4050101@htwk-leipzig.de> <56B4CCEB.5060406@htwk-leipzig.de> <20160205162651.GA28854@weber> <6B40AE7F-84DE-48A2-83FF-1940786CFC1F@cis.upenn.edu> <56B542AF.4070106@artyom.me> Message-ID: <0D986829-3CD7-43C6-92A7-97BB954DB850@cis.upenn.edu> A bit of time away from my keyboard has revealed a natural way to solve this problem and others: be more like Idris. Normally, of course, I'm thinking about how Haskell's type system can be more like Idris's. But that's not what I mean here. I want Haskell's interface to be more like Idris's. Imagine this interchange: ?> :t ($) ($) :: (a -> b) -> a -> b -- click on the type ($) :: forall a b. (a -> b) -> a -> b -- click on the a ($) :: forall (a :: *) b. (a -> b) -> a -> b -- click on the b ($) :: forall (a :: *) (b :: *). (a -> b) -> a -> b -- where b's kind has a different color than usual -- click on b's kind ($) :: forall {r :: RuntimeRep} (a :: *) (b :: TYPE r). (a -> b) -> a -> b -- mouseover RuntimeRep or TYPE reveals a tooltip "($) is representation-polymorphic, meaning that `b` can have an arbitrary runtime representation. Please see http://.... for more details." Similarly, classes would render in a special color, allowing you to click on them and choose to instantiate the type at a few in-scope instances of the class at hand, changing Foldable f => f a -> Int to the much simpler [a] -> Int. This is not a minor engineering project, but it would reap wonderful rewards, addressing the problems in this thread and more. No more lying (because all lies are clickable), no more fragmented language, no more brakes on development. Evidently, Chris already agrees with this proposal: #10073 (https://ghc.haskell.org/trac/ghc/ticket/10073) Also see #8809 (https://ghc.haskell.org/trac/ghc/ticket/8809) Any volunteers to implement this? :) Richard On Feb 5, 2016, at 7:47 PM, Artyom wrote: > I?ve amended my suggestion to say basically ?this type is a slight lie, here?s a flag/command to see the true type? ? this way we aren?t scaring people with implementation guts, merely letting them see the guts for themselves and then think ?I don?t care about this? (which is, I think, exactly what should happen; the worst scenario here is that the beginner falls into the ?I?m an advanced user, I need all features, I need to know everything, so I?ll enable the flag? trap ? which is why it?s important not to call it ?an advanced type? or mention ?if you know what you?re doing? or anything else like that). > > I don?t agree that levity can be compared to Java?s ?class? or ?static? ? not because it?s harder to understand, but because it?s much less widely used; I don?t feel that you need to know about levity in order to be a good Haskeller. Also, unboxed types don?t imply knowledge of levity ? for instance, I?ve been successfully using unboxed types for a while, but I only found out about the true type of ($) by complete accident (I think I queried the kind of -> and then got curious about question marks). Of > > On 02/06/2016 03:27 AM, Mihai Maruseac wrote: > > > >> On Fri, Feb 5, 2016 at 7:09 PM, Richard Eisenberg wrote: >>> Another great question that has come up is about Haddock output (Hackage). I >>> think Haddock needs to add a facility where library authors can include >>> specializations of an overly general type. This can be done in commentary, >>> but it's not as prominent. Such a new feature would address the ($) problem, >>> as ($) :: forall (a :: *) (b :: *). (a -> b) -> a -> b is a specialization >>> of its real type. It would also help a great deal with FTP-related >>> generalizations. >> This goes hand in hand with Artyom's suggestion of a warning in GHCi >> after showing the simpler type. >> >> I'm thinking of a flag which enables/disables printing the simplest >> type with warning (in GHCi) or footnote (or otherwise, in Haddock). We >> can have the default behavior of the flag be either printing the >> simpler type + extra (warning/footnote) or printing the longer type >> and include a reference in our learning materials that beginners and >> people confused by the long, complex and real type, can use >> --use-simpler-types flag. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.farkasdyck at gmail.com Sat Feb 6 02:24:47 2016 From: m.farkasdyck at gmail.com (M Farkas-Dyck) Date: Fri, 5 Feb 2016 18:24:47 -0800 Subject: [Haskell-cafe] Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic) In-Reply-To: <0D986829-3CD7-43C6-92A7-97BB954DB850@cis.upenn.edu> References: <56B4CA58.4050101@htwk-leipzig.de> <56B4CCEB.5060406@htwk-leipzig.de> <20160205162651.GA28854@weber> <6B40AE7F-84DE-48A2-83FF-1940786CFC1F@cis.upenn.edu> <56B542AF.4070106@artyom.me> <0D986829-3CD7-43C6-92A7-97BB954DB850@cis.upenn.edu> Message-ID: On 05/02/2016, Richard Eisenberg wrote: > -- click on the type The question so remains: what would we write to a purely textual terminal? From omeragacan at gmail.com Sat Feb 6 02:50:30 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Fri, 5 Feb 2016 21:50:30 -0500 Subject: StgCase - are LiveVars and SRT fields going to be used? In-Reply-To: References: <7edb9d617aa344ce8b6fcf4d3b27849c@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Simon, I broke the debug build with that commit. I actually validated locally before committing, but apparently the default validate settings doesn't define DEBUG, so the new assertion implementation was not tested. (Why validate doesn't define DEBUG by default???) The fastest way to reproduce the bug is to use these validate settings: DYNAMIC_GHC_PROGRAMS = NO GhcLibWays = v GhcStage1HcOpts += -DDEBUG I did some debugging. Here's an example definition that causes the assertion failure: unpackCString# unpackCString# [InlPrag=NOINLINE] :: Addr# -> [Char] [GblId, Arity=1, Caf=NoCafRefs, Str=DmdType , Unf=OtherCon []] = \r [addr_seX] let { unpack_seY [Occ=LoopBreaker] :: Int# -> [Char] [LclId, Arity=1, Str=DmdType , Unf=OtherCon []] = sat-only \r [nh_seZ] case indexCharOffAddr# [addr_seX nh_seZ] of ch_sf0 { __DEFAULT -> let { sat_sf3 [Occ=Once] :: [Char] [LclId, Str=DmdType] = \u [] case +# [nh_seZ 1#] of sat_sf2 { __DEFAULT -> unpack_seY sat_sf2; }; } in let { sat_sf1 [Occ=Once] :: Char [LclId, Str=DmdType] = NO_CCS C#! [ch_sf0]; } in : [sat_sf1 sat_sf3]; '\NUL'# -> [] []; }; } in unpack_seY 0#; Here the IdInfo says this doesn't have CAF refs, but `sat_sf3` is updatable, so in our assertion we say that this has a CAF. In the implementation I basically followed your description: " - If the binding is an updatable thunk, it has CAF refs. - Otherwise it has CAF reffs iff any of its free Ids (including imported ones) has mayHaveCafRefs in its IdInfo. Actually you can probably ignore the "free" part and just check if any Id has mayHaveCafRefs set. " The first case is why we say "yes" to stgBindHasCafRefs. But I don't quite understand why we say every updatable thunk has CAFs. I think this is only the case with top-level updatable thunks, right? If no, then maybe the problem is not with the assertion but rather with the CorePrep step that sets IdInfos? Any ideas? Thanks.. 2016-02-01 20:19 GMT-05:00 ?mer Sinan A?acan : > https://phabricator.haskell.org/D1880 > > 2016-02-01 18:04 GMT-05:00 Simon Peyton Jones : >> Those fields are dead, now that the Cmm pass deals with it. We left it in while making the transition, but they can go now. Go ahead! >> >> (Lots of code should disappear along with them!) >> >> Simon >> >> | -----Original Message----- >> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of ?mer Sinan >> | Agacan >> | Sent: 01 February 2016 22:06 >> | To: ghc-devs >> | Subject: StgCase - are LiveVars and SRT fields going to be used? >> | >> | Hi all, >> | >> | This is how case expression in STG currently defined: >> | >> | >> | | StgCase >> | (GenStgExpr bndr occ) >> | (GenStgLiveVars occ) >> | (GenStgLiveVars occ) >> | bndr >> | SRT >> | AltType >> | [GenStgAlt bndr occ] >> | >> | >> | The GenStgLiveVars and SRT fields are never used anywhere in the compiler >> | (except the printer). So the question is, I'm assuming those were used at >> | some >> | point, but are they going to be used in the future? Or can I just delete >> | those? >> | >> | As a proof of concept, I just compiled GHC using this: >> | >> | >> | | StgCase >> | (GenStgExpr bndr occ) >> | bndr >> | AltType >> | [GenStgAlt bndr occ] >> | >> | >> | Normally this is not a big deal, but I'm doing lots of STG-to-STG >> | transformations nowadays, and I have to keep those field updated which is >> | annoying as those are never going to be used (I can't even know if I'm doing >> | it >> | right), or leave those `undefined` which is not a good practice. >> | _______________________________________________ >> | 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%7c12ca56c8fc514f477f7f08 >> | d32b53f4bc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=LPiupNbUJ9OGL9cmbP%2f >> | PAs2JSdxqlxk%2bGbXuYTHFbzg%3d From chak at justtesting.org Sat Feb 6 10:57:50 2016 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Sat, 6 Feb 2016 21:57:50 +1100 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: <56B44DCE.5010602@ro-che.info> References: <0210F72D-CCF3-452A-BAD4-15796F288FD9@justtesting.org> <1454628457-sup-7751@sabre> <56B44DCE.5010602@ro-che.info> Message-ID: <2D1FDCA1-90EB-4699-A29B-C706EFE7FC2E@justtesting.org> That makes a lot of sense to me. Manuel > Roman Cheplyaka : > > On 02/05/2016 01:31 AM, Edward Z. Yang wrote: >> I'm not really sure how you would change the type of 'id' based on >> a language pragma. >> >> How do people feel about a cosmetic fix, where we introduce a new >> pragma, {-# LANGUAGE ShowLevity #-} which controls the display of levity >> arguments/TYPE. It's off by default but gets turned on by some >> extensions like MagicHash (i.e. we only show levity if you have >> enabled extensions where the distinction matters). > > Yes, I am surprised this isn't the way it's been done. The levity > arguments should totally be hidden unless requested explicitly. > > I'd only expect this to be a ghc flag (-fshow-levity), not a language > pragma, since it should only affect the way types are /shown/. > > Roman > > _______________________________________________ > 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 Sat Feb 6 12:27:00 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 06 Feb 2016 13:27:00 +0100 Subject: [Haskell-cafe] New type of ($) operator in GHC 8.0 is problematic In-Reply-To: <20160206115920.GA30442@weber> References: <56B4CA58.4050101@htwk-leipzig.de> <56B4CCEB.5060406@htwk-leipzig.de> <20160205162651.GA28854@weber> <6B40AE7F-84DE-48A2-83FF-1940786CFC1F@cis.upenn.edu> <20160205191925.GC28854@weber> <20160206115920.GA30442@weber> Message-ID: <87r3gq9g8b.fsf@smart-cactus.org> Tom Ellis writes: > On Fri, Feb 05, 2016 at 07:19:25PM +0000, Tom Ellis wrote: >> On Fri, Feb 05, 2016 at 01:13:23PM -0500, Richard Eisenberg wrote: >> > We're in a bit of a bind in all this. We really need the fancy type for >> > ($) so that it can be used in all situations where it is used currently. >> >> Is there a list of situations where ($) is used currently that give rise to >> this need? > > Does anyone have any idea about this? What is it about ($) that means it > needs a new funky type whereas (apparently) nothing else does? The first (albeit rather unconvincing) example I can think of is be something like, getI# :: Int -> Int# getI# (I# n#) = n# n# :: Int# n# = getI# $ 5 + 8 Richard likely has something a bit less contrived though. This does raise the question of why ($) is generalized, yet (.) is not, (.) :: forall (l :: Levity) a b (c :: TYPE l). (b -> c) -> (a -> b) -> (a -> c) (.) f g x = f (g x) 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 ghc-devs at stefan-klinger.de Sat Feb 6 13:30:01 2016 From: ghc-devs at stefan-klinger.de (ghc-devs at stefan-klinger.de) Date: Sat, 6 Feb 2016 14:30:01 +0100 Subject: New type of ($) operator in GHC 8.0 is problematic Message-ID: <20160206133000.GA4372@tauhou.fritz.box> Hi there, I'm teaching Haskell to 2nd semester computer science students, and I have been teaching Haskell since 2006. While I certainly do appreciate the constant developement of Haskell, and GHC, I'm becoming more and more concerned about the learning curve involved. For our students it is an entirely new concept that ?Application? can be an operator. They are just learning about associativity. `foldl` and `foldr` are *baffling* concepts to them. They have never thought of functions being values. They have never looked at a strict type system. Having `Foldable` pop up last year already was not optimal, and to be honest, this ($) :: forall (w :: Levity) a (b :: TYPE w). (a -> b) -> a -> b is a disaster for teaching ? Sorry. Richard, thank you very much for your elaborate statement. The problem I see with a `BeginnersPrelude` is that it will either outdate, or create a bubble escaping from which is so painful that most new Haskell programmers will hesitate to take the step. GHC developement will carry on, more and more things being hidden behind `BeginnersPrelude` automatically. We will end up educating Beginners that will want to stay beginners. I'd personally wish for a `-fdefault-levity` switch, but I do not oversee all the consequences right now. I know it puts load on you, but this actually just tells you that the language you're building became a bit less learnable, maybe it's good to be aware of that. Kind regards Stefan -- http://stefan-klinger.de o/X Send plain text messages only, not exceeding 32kB. /\/ \ From roma at ro-che.info Sat Feb 6 14:55:56 2016 From: roma at ro-che.info (Roman Cheplyaka) Date: Sat, 6 Feb 2016 16:55:56 +0200 Subject: Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic) In-Reply-To: References: <56B4CA58.4050101@htwk-leipzig.de> <56B4CCEB.5060406@htwk-leipzig.de> <20160205162651.GA28854@weber> <6B40AE7F-84DE-48A2-83FF-1940786CFC1F@cis.upenn.edu> Message-ID: <56B6097C.1010500@ro-che.info> On 02/06/2016 02:09 AM, Richard Eisenberg wrote: > The old type of ($) was always a lie. -XMagicHash just changes the > parser, allowing the # suffix. It is only by convention that most (all?) > unlifted things end in #. The old type of ($) was perhaps a harmless > lie, but a lie nonetheless. > > Are we comfortable with lying? (Believe me, I'm not trying to impose > some moral dimension to simplifying output!) In my mind, lying about > types like this is in the same space as having a beginner's Prelude. And > people will constantly discover that we're lying and get very confused. > Having a whole host of flags that tell GHC to lie less is somewhat like > having two versions of the language... only the differences manifest > only in output instead of input. > > If we are comfortable with lying in this way: as I've offered, I can > hide the type of ($) (and other representation-polymorphic things) > behind a flag. Easy to do. I would call this a simplification rather than a lie. When in physics we model a falling ball, we normally do not factor in quantum or relativistic effects. Not only would that complicate the calculations immensely, but also make very little difference on the outcome. That applies equally to a high-school physics student and to an engineer. Likewise, /usually/ when we program in Haskell, we do not care about levity polymorphism. If levity stuff pops up in ghci, that would only clutter the output and obscure the important bits, for beginners and experienced users alike. So yes, please do hide the representation-polymorphic artifacts behind a flag, perhaps with a warning whenever something is concealed. But despite all the negativity in this thread, I want to say that your work on this and other aspects of GHC is very much appreciated. Keep it up! Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From spam at scientician.net Sat Feb 6 15:02:46 2016 From: spam at scientician.net (Bardur Arantsson) Date: Sat, 6 Feb 2016 16:02:46 +0100 Subject: Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic) In-Reply-To: <56B6097C.1010500@ro-che.info> References: <56B4CA58.4050101@htwk-leipzig.de> <56B4CCEB.5060406@htwk-leipzig.de> <20160205162651.GA28854@weber> <6B40AE7F-84DE-48A2-83FF-1940786CFC1F@cis.upenn.edu> <56B6097C.1010500@ro-che.info> Message-ID: On 02/06/2016 03:55 PM, Roman Cheplyaka wrote: > But despite all the negativity in this thread, I want to say that your > work on this and other aspects of GHC is very much appreciated. Keep it up! > +1000 From eir at cis.upenn.edu Sat Feb 6 15:17:36 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Sat, 6 Feb 2016 10:17:36 -0500 Subject: Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic) In-Reply-To: <56B6097C.1010500@ro-che.info> References: <56B4CA58.4050101@htwk-leipzig.de> <56B4CCEB.5060406@htwk-leipzig.de> <20160205162651.GA28854@weber> <6B40AE7F-84DE-48A2-83FF-1940786CFC1F@cis.upenn.edu> <56B6097C.1010500@ro-che.info> Message-ID: I have made a ticket #11549 (https://ghc.haskell.org/trac/ghc/ticket/11549) requesting a -fshow-runtime-rep flag (recalling that the name levity will soon be outdated) as described in this thread. I will make sure this gets in for the release of 8.0. Other points: - You're quite right that (.) could be generalized. But I'll wait for someone to really want this. - I don't have a non-contrived example of the use of ($) with unlifted types. It's quite possible that when adding the dirty runST hack, it was observed that an unlifted type would be OK. At that point, the type of ($) didn't need to become so elaborate. And now we're just trying not to change old (but perhaps unrequested) behavior. - For the record, this debate is entirely unrelated to the runST impredicativity hack. (Except, as noted above, perhaps in history.) That hack remains, basically unchanged. - On Feb 6, 2016, at 9:55 AM, Roman Cheplyaka wrote: > > I would call this a simplification rather than a lie. This is a very convincing argument. - Thanks, also, for the voice of support. What I love about the Haskell community is that we can have an impassioned debate full of strong opinions, and it all very rarely devolves into a proper flame war. All the posts I've seen in this thread have been constructive and helpful. Thanks. Richard From ecrockett0 at gmail.com Sat Feb 6 16:16:40 2016 From: ecrockett0 at gmail.com (Eric Crockett) Date: Sat, 6 Feb 2016 11:16:40 -0500 Subject: [GHC] #7803: Superclass methods are left unspecialized In-Reply-To: <058.88b1521af6f479116f61b081f9f91017@haskell.org> References: <043.4332d4a466b84dd410c0fa8f45c15001@haskell.org> <058.88b1521af6f479116f61b081f9f91017@haskell.org> Message-ID: https://ghc.haskell.org/trac/ghc/ticket/7803#comment:12 On Sat, Feb 6, 2016 at 11:14 AM, GHC wrote: > #7803: Superclass methods are left unspecialized > -------------------------------------+------------------------------------- > Reporter: akio | Owner: > Type: bug | Status: new > Priority: normal | Milestone: > Component: Compiler | Version: 7.6.2 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: > Type of failure: Compile-time | Unknown/Multiple > performance bug | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): > Wiki Page: | > -------------------------------------+------------------------------------- > > Comment (by bgamari): > > I've started a pair of builds; I'll put up nofib results once they have > finished. > > -- > Ticket URL: > GHC > The Glasgow Haskell Compiler > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecrockett0 at gmail.com Sat Feb 6 16:17:07 2016 From: ecrockett0 at gmail.com (Eric Crockett) Date: Sat, 6 Feb 2016 11:17:07 -0500 Subject: [GHC] #7803: Superclass methods are left unspecialized In-Reply-To: References: <043.4332d4a466b84dd410c0fa8f45c15001@haskell.org> <058.88b1521af6f479116f61b081f9f91017@haskell.org> Message-ID: My apologies for that. Please ignore. On Sat, Feb 6, 2016 at 11:16 AM, Eric Crockett wrote: > https://ghc.haskell.org/trac/ghc/ticket/7803#comment:12 > > On Sat, Feb 6, 2016 at 11:14 AM, GHC wrote: > >> #7803: Superclass methods are left unspecialized >> >> -------------------------------------+------------------------------------- >> Reporter: akio | Owner: >> Type: bug | Status: new >> Priority: normal | Milestone: >> Component: Compiler | Version: 7.6.2 >> Resolution: | Keywords: >> Operating System: Unknown/Multiple | Architecture: >> Type of failure: Compile-time | Unknown/Multiple >> performance bug | Test Case: >> Blocked By: | Blocking: >> Related Tickets: | Differential Rev(s): >> Wiki Page: | >> >> -------------------------------------+------------------------------------- >> >> Comment (by bgamari): >> >> I've started a pair of builds; I'll put up nofib results once they have >> finished. >> >> -- >> Ticket URL: >> GHC >> The Glasgow Haskell Compiler >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Sat Feb 6 17:09:22 2016 From: ekmett at gmail.com (Edward Kmett) Date: Sat, 6 Feb 2016 12:09:22 -0500 Subject: [Haskell-cafe] New type of ($) operator in GHC 8.0 is problematic In-Reply-To: References: <56B4CA58.4050101@htwk-leipzig.de> <56B4CCEB.5060406@htwk-leipzig.de> <20160205162651.GA28854@weber> <6B40AE7F-84DE-48A2-83FF-1940786CFC1F@cis.upenn.edu> Message-ID: On Fri, Feb 5, 2016 at 6:21 PM, Mike Izbicki wrote: > > We're in a bit of a bind in all this. We really need the fancy type for > ($) > > so that it can be used in all situations where it is used currently. The > old > > type for ($) was just a plain old lie. Now, at least, we're not lying. > So, > > do we 1) lie, 2) allow the language to grow, or 3) avoid certain growth > > because it affects how easy the language is to learn? I don't really > think > > anyone is advocating for (3) exactly, but it's hard to have (2) and not > make > > things more complicated -- unless we have a beginners' mode or other > > features in, say, GHCi that aid learning. As I've said, I'm in full > favor of > > adding these features. > > The old type for ($) is only a lie when the MagicHash extension is > turned on. Otherwise, it is not a lie. I think the best solution is > to pretty print the type depending on what language pragmas are in > use. In GHCI, this would be trivial. The much harder case is haddock > documentation. > Note: The old type of ($) has always been a lie, even without MagicHash, a much stronger lie because the true type of ($) can't even be written in the language today. You can instantiate both the source and target types of ($) to polytypes, not just monotypes. This lets us use ($) in situations like runST $ do ... Having it infer a RankNType through its magical type inference rule there doesn't require an extension on the behalf of the user, even if runST required them at the definition site. -Edward > I think a good way around this would be an eventual patch to haddock > that allows the user to select which extensions they want to use when > browsing documentation. There's a lot of usability issues that would > need to be resolved with this still, but it reduces this technical > discussion we're having down to a design discussion. It also nicely > lets the user specify the level of difficulty they want their prelude > to be without causing incompatibilty with users who want a different > level of prelude. > _______________________________________________ > 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 oleg.grenrus at iki.fi Sat Feb 6 19:07:01 2016 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Sat, 6 Feb 2016 21:07:01 +0200 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: <20160206133000.GA4372@tauhou.fritz.box> References: <20160206133000.GA4372@tauhou.fritz.box> Message-ID: > On 06 Feb 2016, at 15:30, ghc-devs at stefan-klinger.de wrote: > > Richard, thank you very much for your elaborate statement. The > problem I see with a `BeginnersPrelude` is that it will either > outdate, or create a bubble escaping from which is so painful that > most new Haskell programmers will hesitate to take the step. GHC > developement will carry on, more and more things being hidden behind > `BeginnersPrelude` automatically. We will end up educating Beginners > that will want to stay beginners. > > I'd personally wish for a `-fdefault-levity` switch, but I do not > oversee all the consequences right now. I know it puts load on you, > but this actually just tells you that the language you're building > became a bit less learnable, maybe it's good to be aware of that. > > Kind regards > Stefan I came with maybe silly idea: What if we had a way to re-export the symbol with less-general type: module Prelude.YourCourse ( ($) :: (a -> b) -> a -> b, foldr :: (a -> b -> b) -> b -> [a] -> b, ... ) where {-# LANGUAGE NoExplicitPrelude #-} module Main (main) where import Prelude.YourCourse -- but if people need general foldr, you can: import Prelude (foldr) -------------- 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 omeragacan at gmail.com Sat Feb 6 23:39:46 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Sat, 6 Feb 2016 18:39:46 -0500 Subject: StgCase - are LiveVars and SRT fields going to be used? In-Reply-To: References: <7edb9d617aa344ce8b6fcf4d3b27849c@DB4PR30MB030.064d.mgd.msft.net> Message-ID: I submitted https://phabricator.haskell.org/D1889 which hopefully fixes this properly. 2016-02-05 21:50 GMT-05:00 ?mer Sinan A?acan : > Simon, I broke the debug build with that commit. I actually validated locally > before committing, but apparently the default validate settings doesn't define > DEBUG, so the new assertion implementation was not tested. (Why validate > doesn't define DEBUG by default???) > > The fastest way to reproduce the bug is to use these validate settings: > > DYNAMIC_GHC_PROGRAMS = NO > GhcLibWays = v > GhcStage1HcOpts += -DDEBUG > > I did some debugging. Here's an example definition that causes the assertion > failure: > > unpackCString# > unpackCString# [InlPrag=NOINLINE] :: Addr# -> [Char] > [GblId, > Arity=1, > Caf=NoCafRefs, > Str=DmdType , > Unf=OtherCon []] = > \r [addr_seX] > let { > unpack_seY [Occ=LoopBreaker] :: Int# -> [Char] > [LclId, Arity=1, Str=DmdType , Unf=OtherCon []] = > sat-only \r [nh_seZ] > case indexCharOffAddr# [addr_seX nh_seZ] of ch_sf0 { > __DEFAULT -> > let { > sat_sf3 [Occ=Once] :: [Char] > [LclId, Str=DmdType] = > \u [] > case +# [nh_seZ 1#] of sat_sf2 { > __DEFAULT -> unpack_seY sat_sf2; > }; } in > let { > sat_sf1 [Occ=Once] :: Char > [LclId, Str=DmdType] = > NO_CCS C#! [ch_sf0]; > } in : [sat_sf1 sat_sf3]; > '\NUL'# -> [] []; > }; > } in unpack_seY 0#; > > Here the IdInfo says this doesn't have CAF refs, but `sat_sf3` is updatable, so > in our assertion we say that this has a CAF. In the implementation I basically > followed your description: > > " > - If the binding is an updatable thunk, it has CAF refs. > > - Otherwise it has CAF reffs iff any of its free Ids (including imported ones) > has mayHaveCafRefs in its IdInfo. Actually you can probably ignore the "free" > part and just check if any Id has mayHaveCafRefs set. > " > > The first case is why we say "yes" to stgBindHasCafRefs. But I don't quite > understand why we say every updatable thunk has CAFs. I think this is only the > case with top-level updatable thunks, right? If no, then maybe the problem is > not with the assertion but rather with the CorePrep step that sets IdInfos? Any > ideas? > > Thanks.. > > 2016-02-01 20:19 GMT-05:00 ?mer Sinan A?acan : >> https://phabricator.haskell.org/D1880 >> >> 2016-02-01 18:04 GMT-05:00 Simon Peyton Jones : >>> Those fields are dead, now that the Cmm pass deals with it. We left it in while making the transition, but they can go now. Go ahead! >>> >>> (Lots of code should disappear along with them!) >>> >>> Simon >>> >>> | -----Original Message----- >>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of ?mer Sinan >>> | Agacan >>> | Sent: 01 February 2016 22:06 >>> | To: ghc-devs >>> | Subject: StgCase - are LiveVars and SRT fields going to be used? >>> | >>> | Hi all, >>> | >>> | This is how case expression in STG currently defined: >>> | >>> | >>> | | StgCase >>> | (GenStgExpr bndr occ) >>> | (GenStgLiveVars occ) >>> | (GenStgLiveVars occ) >>> | bndr >>> | SRT >>> | AltType >>> | [GenStgAlt bndr occ] >>> | >>> | >>> | The GenStgLiveVars and SRT fields are never used anywhere in the compiler >>> | (except the printer). So the question is, I'm assuming those were used at >>> | some >>> | point, but are they going to be used in the future? Or can I just delete >>> | those? >>> | >>> | As a proof of concept, I just compiled GHC using this: >>> | >>> | >>> | | StgCase >>> | (GenStgExpr bndr occ) >>> | bndr >>> | AltType >>> | [GenStgAlt bndr occ] >>> | >>> | >>> | Normally this is not a big deal, but I'm doing lots of STG-to-STG >>> | transformations nowadays, and I have to keep those field updated which is >>> | annoying as those are never going to be used (I can't even know if I'm doing >>> | it >>> | right), or leave those `undefined` which is not a good practice. >>> | _______________________________________________ >>> | 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%7c12ca56c8fc514f477f7f08 >>> | d32b53f4bc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=LPiupNbUJ9OGL9cmbP%2f >>> | PAs2JSdxqlxk%2bGbXuYTHFbzg%3d From ben at well-typed.com Sun Feb 7 18:13:04 2016 From: ben at well-typed.com (Ben Gamari) Date: Sun, 07 Feb 2016 19:13:04 +0100 Subject: [ANNOUNCE] GHC 8.0.1 release candidate 2 Message-ID: <8737t49yof.fsf@smart-cactus.org> Hello everyone, The GHC Team is very pleased to announce the second release candidate of the Glasgow Haskell Compiler 8.0.1 release. Source and binary distributions as well as the newly revised users guide and Haddock documentation can be found at http://downloads.haskell.org/~ghc/8.0.1-rc2/ This is the second in a series of release candidates leading up to the 8.0.1 release and fixes many of the issues reported in -rc1. These fixes include, * A re-rewrite of the pattern checker by George Karachalias. The new checker should have far more predictable performance characteristics while sacrificing minimal reasoning power. This should resolve a large number of the issues felt in -rc1. * Richard Eisenberg has been hammering out all manner of type-application- and TypeInType-related issues (#11335, #11416, #11405). There is still more work to do here, however (e.g. #11471). * Matthew Pickering has restored support for multi-clause pattern synonyms (#11367) * A latent bug in the constraint solver which popped up as a build failure in xmonad-contrib in -rc1 has been fixed (#11379) * Dimitrios Vytiniotis and Simon Peyton Jones has been squashing a variety of older type-checker bugs at a furious rate (#11458, #11248, #11330, #11408) * Simon Peyton Jones has taught demand analysis to more precisely handle exceptions (#11222) * Tamar Christina has added support for remote GHCi on Windows and resolved a long-standing linking issue (#11223) * Loading of compiled modules needing shared library symbols now works in GHCi thanks to Peter Trommler (#10458) * A variety of limitations in our implementation of Typeable implementation have been fixed (#11120) although there is still more to be done (#11334). * A terrible failure of type inference due to visible type application has been fixed (#11458) * InjectiveTypeFamilies has been renamed to TypeFamilyDependencies * Custom type errors are now more robust (#11391) although there is still more work to be done (#11541) * We now have a more conservative default warning set, as well as better mechanisms for managing warning changes in the future. (#11429, #11370) * Compatibility with earlier Cabal versions should be a bit more robust. * The user-facing interface of the (formerly "implicit") CallStack functionality has been reworked, hiding the implicit callstack parameter behind a constraint synonym. * Online haddock documentation has been restored (#11419) * We now offer xz archives exclusively * A variety of miscellaneous bug-fixes have also been merged. All of these changes add up to nearly 200 commits in total. Given the large amount of churn between this candidate and -rc1, as well as the fact that there is at least one more significant patch pending (D1891, to fix #11471 and others), we will be releasing a third release candidate in a few weeks which should address more of the issues listed on the release status page [1]. Assuming things go well, we should be able to cut a final release by early March at the latest. All of the builds above were produced from the ghc-8.0.1-rc2 tag (commit e2230228906a1c0fa1f86a0c1aa18d87de3cc49d) *with the exception of the Windows builds*. Unfortunately, it was realized only too late that the tagged commit is broken on Windows. Consequently, the Windows builds were produced from the ghc-8.0.1-rc2 tag with two additional patches (commit 5b35c5509adb1311856faa0bc9767aec9ad5e9b7). While this would of course be completely unacceptable for a proper release, time constraints have meant that this was unfortunately the only viable option for this release candidate. We apologize for any confusion this may cause. At this point we are working very hard to nail the remaining bugs labelled as "highest" priority on the 8.0.1 status page [1]. If you have an issue which you'd like to see addressed in the release that does not appear in this list, please bring it to our attention. As always, we look forward to hearing about any issues that you encounter with this candidate. Thanks to everyone who has contributed so far! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From george.colpitts at gmail.com Sun Feb 7 18:21:08 2016 From: george.colpitts at gmail.com (George Colpitts) Date: Sun, 7 Feb 2016 14:21:08 -0400 Subject: [ANNOUNCE] GHC 8.0.1 release candidate 2 In-Reply-To: <8737t49yof.fsf@smart-cactus.org> References: <8737t49yof.fsf@smart-cactus.org> Message-ID: Good news! I assume there will be a Mac OS binary distribution soon? On Sun, Feb 7, 2016 at 2:13 PM, Ben Gamari wrote: > > Hello everyone, > > The GHC Team is very pleased to announce the second release candidate of > the Glasgow Haskell Compiler 8.0.1 release. Source and binary > distributions as well as the newly revised users guide and Haddock > documentation can be found at > > http://downloads.haskell.org/~ghc/8.0.1-rc2/ > > This is the second in a series of release candidates leading up to the > 8.0.1 > release and fixes many of the issues reported in -rc1. These fixes > include, > > * A re-rewrite of the pattern checker by George Karachalias. The new > checker should have far more predictable performance characteristics > while sacrificing minimal reasoning power. This should resolve a > large number of the issues felt in -rc1. > > * Richard Eisenberg has been hammering out all manner of > type-application- and TypeInType-related issues (#11335, #11416, > #11405). There is still more work to do here, however (e.g. #11471). > > * Matthew Pickering has restored support for multi-clause pattern > synonyms (#11367) > > * A latent bug in the constraint solver which popped up as a build > failure in xmonad-contrib in -rc1 has been fixed (#11379) > > * Dimitrios Vytiniotis and Simon Peyton Jones has been squashing a > variety of older type-checker bugs at a furious rate (#11458, > #11248, #11330, #11408) > > * Simon Peyton Jones has taught demand analysis to more precisely > handle exceptions (#11222) > > * Tamar Christina has added support for remote GHCi on Windows > and resolved a long-standing linking issue (#11223) > > * Loading of compiled modules needing shared library symbols now works > in GHCi thanks to Peter Trommler (#10458) > > * A variety of limitations in our implementation of Typeable > implementation have been fixed (#11120) although there is still more > to be done (#11334). > > * A terrible failure of type inference due to visible type application > has > been fixed (#11458) > > * InjectiveTypeFamilies has been renamed to TypeFamilyDependencies > > * Custom type errors are now more robust (#11391) although there is > still more work to be done (#11541) > > * We now have a more conservative default warning set, as well as > better mechanisms for managing warning changes in the future. > (#11429, #11370) > > * Compatibility with earlier Cabal versions should be a bit more > robust. > > * The user-facing interface of the (formerly "implicit") CallStack > functionality has been reworked, hiding the implicit callstack > parameter behind a constraint synonym. > > * Online haddock documentation has been restored (#11419) > > * We now offer xz archives exclusively > > * A variety of miscellaneous bug-fixes have also been merged. > > All of these changes add up to nearly 200 commits in total. Given the > large amount of churn between this candidate and -rc1, as well as the > fact that there is at least one more significant patch pending (D1891, > to fix #11471 and others), we will be releasing a third release > candidate in a few weeks which should address more of the issues listed > on the release status page [1]. Assuming things go well, we should be > able to cut a final release by early March at the latest. > > All of the builds above were produced from the ghc-8.0.1-rc2 tag (commit > e2230228906a1c0fa1f86a0c1aa18d87de3cc49d) *with the exception of the > Windows builds*. Unfortunately, it was realized only too late that the > tagged commit is broken on Windows. Consequently, the Windows builds > were produced from the ghc-8.0.1-rc2 tag with two additional patches > (commit 5b35c5509adb1311856faa0bc9767aec9ad5e9b7). While this would of > course be completely unacceptable for a proper release, time constraints > have meant that this was unfortunately the only viable option for this > release candidate. We apologize for any confusion this may cause. > > At this point we are working very hard to nail the remaining bugs > labelled as "highest" priority on the 8.0.1 status page [1]. If you have > an issue which you'd like to see addressed in the release that does not > appear in this list, please bring it to our attention. > > As always, we look forward to hearing about any issues that you > encounter with this candidate. Thanks to everyone who has contributed so > far! > > Cheers, > > - Ben > > > [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1 > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Sun Feb 7 18:39:49 2016 From: ben at well-typed.com (Ben Gamari) Date: Sun, 07 Feb 2016 19:39:49 +0100 Subject: [ANNOUNCE] GHC 8.0.1 release candidate 2 In-Reply-To: References: <8737t49yof.fsf@smart-cactus.org> Message-ID: <87zivc8ive.fsf@smart-cactus.org> George Colpitts writes: > Good news! I assume there will be a Mac OS binary distribution soon? > There is one currently; "Darwin" is the name of the Mac OS X kernel. 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 Sun Feb 7 18:43:18 2016 From: ben at well-typed.com (Ben Gamari) Date: Sun, 07 Feb 2016 19:43:18 +0100 Subject: [ANNOUNCE] GHC 8.0.1 release candidate 2 In-Reply-To: <87zivc8ive.fsf@smart-cactus.org> References: <8737t49yof.fsf@smart-cactus.org> <87zivc8ive.fsf@smart-cactus.org> Message-ID: <87wpqg8ipl.fsf@smart-cactus.org> Ben Gamari writes: > George Colpitts writes: > >> Good news! I assume there will be a Mac OS binary distribution soon? >> > There is one currently; "Darwin" is the name of the Mac OS X kernel. > Hmm, I should have fact-checked that first: XNU is apparently the name of the kernel whereas Darwin is the name of the operating system itself [1]. Regardless, the point is that OS X binaries are available for your testing pleasure. Let us know how it goes! Cheers, - Ben [1] https://en.wikipedia.org/wiki/Darwin_%28operating_system%29 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From george.colpitts at gmail.com Sun Feb 7 19:45:10 2016 From: george.colpitts at gmail.com (George Colpitts) Date: Sun, 7 Feb 2016 15:45:10 -0400 Subject: problem compiling GHC 8.0.1 release candidate 2 src on Apple Message-ID: "/usr/local/bin/ghc" -M -static -H32m -O -Wall -package-db libraries/bootstrapping.conf -this-unit-id terminfo-0.4.0.2 -hide-all-packages -i -ilibraries/terminfo/. -ilibraries/terminfo/dist-boot/build -ilibraries/terminfo/dist-boot/build/autogen -Ilibraries/terminfo/dist-boot/build -Ilibraries/terminfo/dist-boot/build/autogen -Ilibraries/terminfo/. -optP-include -optPlibraries/terminfo/dist-boot/build/autogen/cabal_macros.h -package-id base-4.9.0.0 -Wall -XHaskell2010 -no-user-package-db -rtsopts -fno-warn-unused-imports -fno-warn-deprecated-flags -odir libraries/terminfo/dist-boot/build -hidir libraries/terminfo/dist-boot/build -stubdir libraries/terminfo/dist-boot/build -dep-makefile libraries/terminfo/dist-boot/build/.depend-v.haskell.tmp -dep-suffix "" -include-pkg-deps libraries/terminfo/./System/Console/Terminfo.hs libraries/terminfo/./System/Console/Terminfo/Base.hs libraries/terminfo/./System/Console/Terminfo/Cursor.hs libraries/terminfo/./System/Console/Terminfo/Color.hs libraries/terminfo/./System/Console/Terminfo/Edit.hs libraries/terminfo/./System/Console/Terminfo/Effects.hs libraries/terminfo/./System/Console/Terminfo/Keys.hs ghc: unrecognised flag: -this-unit-id Usage: For basic information, try the `--help' option. make[1]: *** [libraries/terminfo/dist-boot/build/.depend-v.haskell] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv -fno-builtin") ,("C compiler command","/usr/local/bin/gcc") ,("C compiler flags"," -m64 -fno-stack-protector") ,("C compiler link flags"," -m64") ,("Haskell CPP command","/usr/local/bin/gcc") ,("Haskell CPP flags","-E -undef -traditional") ,("ld command","/usr/bin/ld") ,("ld flags"," -arch x86_64") ,("ld supports compact unwind","YES") ,("ld supports build-id","NO") ,("ld supports filelist","YES") ,("ld is GNU ld","NO") ,("ar command","/usr/bin/ar") ,("ar flags","clqs") ,("ar supports at file","NO") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("cross compiling","NO") ,("target os","OSDarwin") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","True") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","8.0.0.20160111") ,("Project Git commit id","497454fc6610d67a2b2cd7902390c6497bddb483") ,("Booter version","7.10.2") ,("Stage","2") ,("Build platform","x86_64-apple-darwin") ,("Host platform","x86_64-apple-darwin") ,("Target platform","x86_64-apple-darwin") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") ,("RTS expects libdw","NO") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Support reexported-modules","YES") ,("Support thinning and renaming package flags","YES") ,("Requires unified installed package IDs","YES") ,("Uses package keys","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("GHC Profiled","NO") ,("Leading underscore","YES") ,("Debug on","False") ,("LibDir","/usr/local/lib/ghc-8.0.0.20160111") ,("Global Package DB","/usr/local/lib/ghc-8.0.0.20160111/package.conf.d") ] On Sun, Feb 7, 2016 at 2:13 PM, Ben Gamari wrote: > > Hello everyone, > > The GHC Team is very pleased to announce the second release candidate of > the Glasgow Haskell Compiler 8.0.1 release. Source and binary > distributions as well as the newly revised users guide and Haddock > documentation can be found at > > http://downloads.haskell.org/~ghc/8.0.1-rc2/ > > This is the second in a series of release candidates leading up to the > 8.0.1 > release and fixes many of the issues reported in -rc1. These fixes > include, > > * A re-rewrite of the pattern checker by George Karachalias. The new > checker should have far more predictable performance characteristics > while sacrificing minimal reasoning power. This should resolve a > large number of the issues felt in -rc1. > > * Richard Eisenberg has been hammering out all manner of > type-application- and TypeInType-related issues (#11335, #11416, > #11405). There is still more work to do here, however (e.g. #11471). > > * Matthew Pickering has restored support for multi-clause pattern > synonyms (#11367) > > * A latent bug in the constraint solver which popped up as a build > failure in xmonad-contrib in -rc1 has been fixed (#11379) > > * Dimitrios Vytiniotis and Simon Peyton Jones has been squashing a > variety of older type-checker bugs at a furious rate (#11458, > #11248, #11330, #11408) > > * Simon Peyton Jones has taught demand analysis to more precisely > handle exceptions (#11222) > > * Tamar Christina has added support for remote GHCi on Windows > and resolved a long-standing linking issue (#11223) > > * Loading of compiled modules needing shared library symbols now works > in GHCi thanks to Peter Trommler (#10458) > > * A variety of limitations in our implementation of Typeable > implementation have been fixed (#11120) although there is still more > to be done (#11334). > > * A terrible failure of type inference due to visible type application > has > been fixed (#11458) > > * InjectiveTypeFamilies has been renamed to TypeFamilyDependencies > > * Custom type errors are now more robust (#11391) although there is > still more work to be done (#11541) > > * We now have a more conservative default warning set, as well as > better mechanisms for managing warning changes in the future. > (#11429, #11370) > > * Compatibility with earlier Cabal versions should be a bit more > robust. > > * The user-facing interface of the (formerly "implicit") CallStack > functionality has been reworked, hiding the implicit callstack > parameter behind a constraint synonym. > > * Online haddock documentation has been restored (#11419) > > * We now offer xz archives exclusively > > * A variety of miscellaneous bug-fixes have also been merged. > > All of these changes add up to nearly 200 commits in total. Given the > large amount of churn between this candidate and -rc1, as well as the > fact that there is at least one more significant patch pending (D1891, > to fix #11471 and others), we will be releasing a third release > candidate in a few weeks which should address more of the issues listed > on the release status page [1]. Assuming things go well, we should be > able to cut a final release by early March at the latest. > > All of the builds above were produced from the ghc-8.0.1-rc2 tag (commit > e2230228906a1c0fa1f86a0c1aa18d87de3cc49d) *with the exception of the > Windows builds*. Unfortunately, it was realized only too late that the > tagged commit is broken on Windows. Consequently, the Windows builds > were produced from the ghc-8.0.1-rc2 tag with two additional patches > (commit 5b35c5509adb1311856faa0bc9767aec9ad5e9b7). While this would of > course be completely unacceptable for a proper release, time constraints > have meant that this was unfortunately the only viable option for this > release candidate. We apologize for any confusion this may cause. > > At this point we are working very hard to nail the remaining bugs > labelled as "highest" priority on the 8.0.1 status page [1]. If you have > an issue which you'd like to see addressed in the release that does not > appear in this list, please bring it to our attention. > > As always, we look forward to hearing about any issues that you > encounter with this candidate. Thanks to everyone who has contributed so > far! > > Cheers, > > - Ben > > > [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1 > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Sun Feb 7 21:14:44 2016 From: ben at well-typed.com (Ben Gamari) Date: Sun, 07 Feb 2016 22:14:44 +0100 Subject: problem compiling GHC 8.0.1 release candidate 2 src on Apple In-Reply-To: References: Message-ID: <87twlk8bp7.fsf@smart-cactus.org> George Colpitts writes: snip > ,("target has GNU nonexec stack","False") > ,("target has .ident directive","True") > ,("target has subsections via symbols","True") > ,("Unregisterised","NO") > ,("LLVM llc command","llc") > ,("LLVM opt command","opt") > ,("Project version","8.0.0.20160111") It looks like you are trying to use rc1 to bootstrap rc2 which is not a supported configuration. Perhaps you could try bootstrapping with 7.10? 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 pali.gabor at gmail.com Sun Feb 7 23:04:14 2016 From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=) Date: Mon, 8 Feb 2016 00:04:14 +0100 Subject: [ANNOUNCE] GHC 8.0.1 release candidate 2 In-Reply-To: <8737t49yof.fsf@smart-cactus.org> References: <8737t49yof.fsf@smart-cactus.org> Message-ID: Hello there, 2016-02-07 19:13 GMT+01:00 Ben Gamari : > The GHC Team is very pleased to announce the second release candidate of > the Glasgow Haskell Compiler 8.0.1 release. For the FreeBSD users, the vanilla binary distributions are available here, along with a brief installation guide: http://haskell.inf.elte.hu/ghc/8.0.0.20160204/ Cheers, G?bor From takenobu.hs at gmail.com Mon Feb 8 10:08:55 2016 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Mon, 8 Feb 2016 19:08:55 +0900 Subject: [Haskell-cafe] Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic) In-Reply-To: References: <56B4CA58.4050101@htwk-leipzig.de> <56B4CCEB.5060406@htwk-leipzig.de> <20160205162651.GA28854@weber> <6B40AE7F-84DE-48A2-83FF-1940786CFC1F@cis.upenn.edu> <56B6097C.1010500@ro-che.info> Message-ID: Hi Richard and devs, What a wonderful (#11549) ! This is a beautiful solution for beginners/newcomers. Beginners will not confuse and they can gradually go ahead. I extremely appreciate that you are continuously improving the ghc for us. Thank you very much, Takenobu 2016-02-07 0:17 GMT+09:00 Richard Eisenberg : > I have made a ticket #11549 (https://ghc.haskell.org/trac/ghc/ticket/11549) > requesting a -fshow-runtime-rep flag (recalling that the name levity will > soon be outdated) as described in this thread. I will make sure this gets > in for the release of 8.0. > > Other points: > > - You're quite right that (.) could be generalized. But I'll wait for > someone to really want this. > > - I don't have a non-contrived example of the use of ($) with unlifted > types. It's quite possible that when adding the dirty runST hack, it was > observed that an unlifted type would be OK. At that point, the type of ($) > didn't need to become so elaborate. And now we're just trying not to change > old (but perhaps unrequested) behavior. > > - For the record, this debate is entirely unrelated to the runST > impredicativity hack. (Except, as noted above, perhaps in history.) That > hack remains, basically unchanged. > > - On Feb 6, 2016, at 9:55 AM, Roman Cheplyaka wrote: > > > > I would call this a simplification rather than a lie. > > This is a very convincing argument. > > - Thanks, also, for the voice of support. What I love about the Haskell > community is that we can have an impassioned debate full of strong > opinions, and it all very rarely devolves into a proper flame war. All the > posts I've seen in this thread have been constructive and helpful. Thanks. > > Richard > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Mon Feb 8 10:38:19 2016 From: ben at well-typed.com (Ben Gamari) Date: Mon, 08 Feb 2016 11:38:19 +0100 Subject: [ANNOUNCE] GHC 8.0.1 release candidate 2 In-Reply-To: References: <8737t49yof.fsf@smart-cactus.org> Message-ID: <87r3gn8p2c.fsf@smart-cactus.org> P?li G?bor J?nos writes: > Hello there, > > 2016-02-07 19:13 GMT+01:00 Ben Gamari : >> The GHC Team is very pleased to announce the second release candidate of >> the Glasgow Haskell Compiler 8.0.1 release. > > For the FreeBSD users, the vanilla binary distributions are available > here, along with a brief installation guide: > Thanks P?li! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ben at well-typed.com Mon Feb 8 11:04:57 2016 From: ben at well-typed.com (Ben Gamari) Date: Mon, 08 Feb 2016 12:04:57 +0100 Subject: [ANNOUNCE] GHC 8.0.1 release candidate 2 In-Reply-To: <8737t49yof.fsf@smart-cactus.org> References: <8737t49yof.fsf@smart-cactus.org> Message-ID: <87oabr8nty.fsf@smart-cactus.org> Ben Gamari writes: > Hello everyone, > snip > > * Compatibility with earlier Cabal versions should be a bit more > robust. > Unfortunately this characterization was perhaps a bit optimistic. Sadly the errors provided by GHC when used with an older Cabal aren't any better in -rc2 than they were in -rc1. I've opened #11558 to track this issue. Users seeing unexpected missing interface file errors need to update Cabal and cabal-install from git. This must be done using GHC 7.10 at the moment as some of Cabal's build dependencies lack a build plan with 8.0. $ git clone git://github.com/haskell/cabal $ cd cabal $ cabal update $ cabal install Cabal/ cabal-install/ 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 wojtek at power.com.pl Mon Feb 8 15:36:36 2016 From: wojtek at power.com.pl (=?UTF-8?Q?Wojtek_Narczy=c5=84ski?=) Date: Mon, 8 Feb 2016 16:36:36 +0100 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: <305900D6-F152-4670-9EA1-6F33D6A63D67@cis.upenn.edu> References: <0210F72D-CCF3-452A-BAD4-15796F288FD9@justtesting.org> <1454628457-sup-7751@sabre> <56B44DCE.5010602@ro-che.info> <1454663966.1570.1.camel@joachim-breitner.de> <305900D6-F152-4670-9EA1-6F33D6A63D67@cis.upenn.edu> Message-ID: <56B8B604.9030804@power.com.pl> On 05.02.2016 14:49, Richard Eisenberg wrote: > - Edward is right in that (->) isn't really levity-polymorphic. Well, > it is, but it's ad hoc polymorphism not parametric polymorphism. > Perhaps in the future we'll make this more robust by actually using > type-classes to control it, as we probably should. > Could you make (->) work for values of types of user defined kinds? -- Wojtek -------------- next part -------------- An HTML attachment was scrubbed... URL: From wojtek at power.com.pl Mon Feb 8 15:42:07 2016 From: wojtek at power.com.pl (=?UTF-8?Q?Wojtek_Narczy=c5=84ski?=) Date: Mon, 8 Feb 2016 16:42:07 +0100 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: <56B8B604.9030804@power.com.pl> References: <0210F72D-CCF3-452A-BAD4-15796F288FD9@justtesting.org> <1454628457-sup-7751@sabre> <56B44DCE.5010602@ro-che.info> <1454663966.1570.1.camel@joachim-breitner.de> <305900D6-F152-4670-9EA1-6F33D6A63D67@cis.upenn.edu> <56B8B604.9030804@power.com.pl> Message-ID: <56B8B74F.500@power.com.pl> On 08.02.2016 16:36, Wojtek Narczy?ski wrote: > On 05.02.2016 14:49, Richard Eisenberg wrote: >> - Edward is right in that (->) isn't really levity-polymorphic. Well, >> it is, but it's ad hoc polymorphism not parametric polymorphism. >> Perhaps in the future we'll make this more robust by actually using >> type-classes to control it, as we probably should. >> > Could you make (->) work for values of types of user defined kinds? > I overdid it. I meant: Could you make (->) work types of user defined kinds? I mean more-less normal functions, only with types of kinds other than * and #. -- Wojtek -------------- next part -------------- An HTML attachment was scrubbed... URL: From wojtek at power.com.pl Mon Feb 8 19:36:07 2016 From: wojtek at power.com.pl (=?UTF-8?Q?Wojtek_Narczy=c5=84ski?=) Date: Mon, 8 Feb 2016 20:36:07 +0100 Subject: Expected a type In-Reply-To: <87oabr8nty.fsf@smart-cactus.org> References: <8737t49yof.fsf@smart-cactus.org> <87oabr8nty.fsf@smart-cactus.org> Message-ID: <56B8EE27.3070202@power.com.pl> Dear Devs, I've tried to ask this in the ($) thread, but it was totally offtopic there and I was ignored just as I deserved :-) Consider the following example. wojtek at Desktop2016:~/src/he$ cat kinds.hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} data K = A | B f :: (A :: K) -> (B :: K) f _ = undefined wojtek at Desktop2016:~/src/he$ /opt/ghc/head/bin/ghc kinds.hs [1 of 1] Compiling Main ( kinds.hs, kinds.o ) kinds.hs:6:6: error: ? Expected a type, but ?'A? has kind ?K? ? In the type signature: f :: (A :: K) -> (B :: K) kinds.hs:6:18: error: ? Expected a type, but ?'B? has kind ?K? ? In the type signature: f :: (A :: K) -> (B :: K) As Roman kindly (!) explained to me some time ago, GHC really means "Expected a type of kind '*' (or '#')..." Now that GHC is apparently undergoing a major overhaul of its internals, would it be possible to allow types of various kinds in functions? Would it make sense? May I file a ticket? -- Kind regards, Wojtek Narczynski From rwbarton at gmail.com Mon Feb 8 19:53:39 2016 From: rwbarton at gmail.com (Reid Barton) Date: Mon, 8 Feb 2016 14:53:39 -0500 Subject: Expected a type In-Reply-To: <56B8EE27.3070202@power.com.pl> References: <8737t49yof.fsf@smart-cactus.org> <87oabr8nty.fsf@smart-cactus.org> <56B8EE27.3070202@power.com.pl> Message-ID: On Mon, Feb 8, 2016 at 2:36 PM, Wojtek Narczy?ski wrote: > Dear Devs, > > I've tried to ask this in the ($) thread, but it was totally offtopic > there and I was ignored just as I deserved :-) > > Consider the following example. > > wojtek at Desktop2016:~/src/he$ cat kinds.hs > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE KindSignatures #-} > > data K = A | B > > f :: (A :: K) -> (B :: K) > f _ = undefined > > wojtek at Desktop2016:~/src/he$ /opt/ghc/head/bin/ghc kinds.hs > [1 of 1] Compiling Main ( kinds.hs, kinds.o ) > > kinds.hs:6:6: error: > ? Expected a type, but ?'A? has kind ?K? > ? In the type signature: > f :: (A :: K) -> (B :: K) > > kinds.hs:6:18: error: > ? Expected a type, but ?'B? has kind ?K? > ? In the type signature: > f :: (A :: K) -> (B :: K) > > As Roman kindly (!) explained to me some time ago, GHC really means > "Expected a type of kind '*' (or '#')..." > > Now that GHC is apparently undergoing a major overhaul of its internals, > would it be possible to allow types of various kinds in functions? Would it > make sense? May I file a ticket? Normally the reason to define a function is so that you can apply it to something. But there are no values of the promoted type A to apply f to, aside from perhaps undefined. What would be the purpose of allowing this? Regards, Reid Barton -------------- next part -------------- An HTML attachment was scrubbed... URL: From wojtek at power.com.pl Mon Feb 8 20:34:18 2016 From: wojtek at power.com.pl (=?UTF-8?Q?Wojtek_Narczy=c5=84ski?=) Date: Mon, 8 Feb 2016 21:34:18 +0100 Subject: Expected a type In-Reply-To: References: <8737t49yof.fsf@smart-cactus.org> <87oabr8nty.fsf@smart-cactus.org> <56B8EE27.3070202@power.com.pl> Message-ID: <56B8FBCA.7090204@power.com.pl> On 08.02.2016 20:53, Reid Barton wrote: > > Normally the reason to define a function is so that you can apply it > to something. But there are no values of the promoted type A to apply > f to, aside from perhaps undefined. What would be the purpose of > allowing this? > Okay, this would be of no use. It didn't occur to me that there is currently no way to have values of types A and B. -- Wojtek From rf at rufflewind.com Mon Feb 8 23:05:34 2016 From: rf at rufflewind.com (Phil Ruffwind) Date: Mon, 8 Feb 2016 18:05:34 -0500 Subject: Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic) In-Reply-To: References: <56B4CA58.4050101@htwk-leipzig.de> <56B4CCEB.5060406@htwk-leipzig.de> <20160205162651.GA28854@weber> <6B40AE7F-84DE-48A2-83FF-1940786CFC1F@cis.upenn.edu> Message-ID: > Another great question that has come up is about Haddock output (Hackage). I > think Haddock needs to add a facility where library authors can include > specializations of an overly general type. This can be done in commentary, > but it's not as prominent. I think a low-hanging fruit would be to add the ability for Haddock to parse some sort of specialized types annotation (could be entirely in the comments) and display them adjacent to the true type. The types do have to be manually written, but at least they can be type-checked. Lens does this in its documentation and they are very helpful for learning the library. > (^.) :: s -> Getting a s a -> a > (^.) :: s -> Getter s a -> a > (^.) :: Monoid m => s -> Fold s m -> m > (^.) :: s -> Iso' s a -> a > (^.) :: s -> Lens' s a -> a > (^.) :: Monoid m => s -> Traversal' s m -> m From mail at joachim-breitner.de Tue Feb 9 08:47:42 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 09 Feb 2016 09:47:42 +0100 Subject: [ANNOUNCE] GHC 8.0.1 release candidate 2 In-Reply-To: <8737t49yof.fsf@smart-cactus.org> References: <8737t49yof.fsf@smart-cactus.org> Message-ID: <1455007662.1636.3.camel@joachim-breitner.de> Hi, Am Sonntag, den 07.02.2016, 19:13 +0100 schrieb Ben Gamari: > As always, we look forward to hearing about any issues that you > encounter with this candidate. Thanks to everyone who has contributed so > far! I cannot bootstrap 8.0.1-rc2 with 8.0.1-rc1 ? ?Bootstrapping using???: /usr/bin/ghc ??????which is version???: 8.0.0.20160111 [..] "rm" -f compiler/stage1/build/.depend-v.haskell.tmp?? "/usr/bin/ghc" -M -static??-H32m -O -lffi -optl-pthread -optl-B/usr/bin/ld.gold -Wall???-package-db libraries/bootstrapping.conf??-this-unit-id ghc-8.0.0.20160204 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage1/build -icompiler/stage1/build/autogen -Icompiler/stage1/build -Icompiler/stage1/build/autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/stage1????-optP-include -optPcompiler/stage1/build/autogen/cabal_macros.h -package-id array-0.5.1.0 -package-id base-4.9.0.0 -package-id binary-0.8.2.0 -package-id bytestring-0.10.7.0 -package-id containers-0.5.7.1 -package-id directory-1.2.5.0 -package-id filepath-1.4.1.0 -package-id ghc-boot-8.0.0.20160204 -package-id hoopl-3.10.2.1 -package-id hpc-0.6.0.3 -package-id process-1.4.1.0 -package-id template-haskell-2.11.0.0 -package-id time-1.6 -package-id transformers-0.5.1.0 -package-id unix-2.7.1.1 -Wall -fno-warn-name-shadowing -this-unit-id ghc -XHaskell2010 -DNO_REGS -DNOSMP -optc-DNOSMP -DSTAGE=1 -Rghc-timing???-no-user-package-db -rtsopts???????-odir compiler/stage1/build -hidir compiler/stage1/build -stubdir compiler/stage1/build -dep-makefile compiler/stage1/build/.depend-v.haskell.tmp -dep-suffix "" -include-pkg-deps??compiler/basicTypes/Avail.hs??compiler/basicTypes/BasicTypes.hs??compiler/basicTypes/ConLike.hs??compiler/basicTypes/DataCon.hs??compiler/basicTypes/PatSyn.hs??compiler/basicTypes/Demand.hs??compiler/cmm/Debug.hs??compiler/utils/Exception.hs??compiler/basicTypes/FieldLabel.hs??compiler/main/GhcMonad.hs??compiler/main/Hooks.hs??compiler/basicTypes/Id.hs??compiler/basicTypes/IdInfo.hs??compiler/basicTypes/Lexeme.hs??compiler/basicTypes/Literal.hs??compiler/llvmGen/Llvm.hs??compiler/llvmGen/Llvm/AbsSyn.hs??compiler/llvmGen/Llvm/MetaData.hs??compiler/llvmGen/Llvm/PpLlvm.hs??compiler/llvmGen/Llvm/Types.hs??compiler/llvmGen/LlvmCodeGen.hs??compiler/llvmGen/LlvmCodeGen/Base.hs??compiler/llvmGen/LlvmCodeGen/CodeGen.hs??compiler/llvmGen/LlvmCodeGen/Data.hs??compiler/llvmGen/LlvmCodeGen/Ppr.hs??compiler/llvmGen/LlvmCodeGen/Regs.hs??compiler/llvmGen/LlvmMangler.hs??compiler/basicTypes/MkId.hs??compiler/basicTypes/Module.hs??compiler/basicTypes/Name.hs??compiler/basicTypes/NameEnv.hs??compiler/basicTypes/NameSet.hs??compiler/basicTypes/OccName.hs??compiler/basicTypes/RdrName.hs??compiler/basicTypes/SrcLoc.hs??compiler/basicTypes/UniqSupply.hs??compiler/basicTypes/Unique.hs??compiler/basicTypes/Var.hs??compiler/basicTypes/VarEnv.hs??compiler/basicTypes/VarSet.hs??compiler/utils/UnVarGraph.hs??compiler/cmm/BlockId.hs??compiler/cmm/CLabel.hs??compiler/cmm/Cmm.hs??compiler/cmm/CmmBuildInfoTables.hs??compiler/cmm/CmmPipeline.hs??compiler/cmm/CmmCallConv.hs??compiler/cmm/CmmCommonBlockElim.hs??compiler/cmm/CmmImplementSwitchPlans.hs??compiler/cmm/CmmContFlowOpt.hs??compiler/cmm/CmmExpr.hs??compiler/cmm/CmmInfo.hs??compiler/cmm/CmmLex.hs??compiler/cmm/CmmLint.hs??compiler/cmm/CmmLive.hs??compiler/cmm/CmmMachOp.hs??compiler/cmm/CmmSwitch.hs??compiler/cmm/CmmNode.hs??compiler/cmm/CmmOpt.hs??compiler/cmm/CmmParse.hs??compiler/cmm/CmmProcPoint.hs??compiler/cmm/CmmSink.hs??compiler/cmm/CmmType.hs??compiler/cmm/CmmUtils.hs??compiler/cmm/CmmLayoutStack.hs??compiler/cmm/MkGraph.hs??compiler/nativeGen/PprBase.hs??compiler/cmm/PprC.hs??compiler/cmm/PprCmm.hs??compiler/cmm/PprCmmDecl.hs??compiler/cmm/PprCmmExpr.hs??compiler/cmm/Bitmap.hs??compiler/codeGen/CodeGen/Platform.hs??compiler/codeGen/CodeGen/Platform/ARM.hs??compiler/codeGen/CodeGen/Platform/ARM64.hs??compiler/codeGen/CodeGen/Platform/NoRegs.hs??compiler/codeGen/CodeGen/Platform/PPC.hs??compiler/codeGen/CodeGen/Platform/PPC_Darwin.hs??compiler/codeGen/CodeGen/Platform/SPARC.hs??compiler/codeGen/CodeGen/Platform/X86.hs??compiler/codeGen/CodeGen/Platform/X86_64.hs??compiler/codeGen/CgUtils.hs??compiler/codeGen/StgCmm.hs??compiler/codeGen/StgCmmBind.hs??compiler/codeGen/StgCmmClosure.hs??compiler/codeGen/StgCmmCon.hs??compiler/codeGen/StgCmmEnv.hs??compiler/codeGen/StgCmmExpr.hs??compiler/codeGen/StgCmmForeign.hs??compiler/codeGen/StgCmmHeap.hs??compiler/codeGen/StgCmmHpc.hs??compiler/codeGen/StgCmmArgRep.hs??compiler/codeGen/StgCmmLayout.hs??compiler/codeGen/StgCmmMonad.hs??compiler/codeGen/StgCmmPrim.hs??compiler/codeGen/StgCmmProf.hs??compiler/codeGen/StgCmmTicky.hs??compiler/codeGen/StgCmmUtils.hs??compiler/codeGen/StgCmmExtCode.hs??compiler/cmm/SMRep.hs??compiler/coreSyn/CoreArity.hs??compiler/coreSyn/CoreFVs.hs??compiler/coreSyn/CoreLint.hs??compiler/coreSyn/CorePrep.hs??compiler/coreSyn/CoreSubst.hs??compiler/coreSyn/CoreSyn.hs??compiler/coreSyn/TrieMap.hs??compiler/coreSyn/CoreTidy.hs??compiler/coreSyn/CoreUnfold.hs??compiler/coreSyn/CoreUtils.hs??compiler/coreSyn/CoreSeq.hs??compiler/coreSyn/CoreStats.hs??compiler/coreSyn/MkCore.hs??compiler/coreSyn/PprCore.hs??compiler/deSugar/PmExpr.hs??compiler/deSugar/TmOracle.hs??compiler/deSugar/Check.hs??compiler/deSugar/Coverage.hs??compiler/deSugar/Desugar.hs??compiler/deSugar/DsArrows.hs??compiler/deSugar/DsBinds.hs??compiler/deSugar/DsCCall.hs??compiler/deSugar/DsExpr.hs??compiler/deSugar/DsForeign.hs??compiler/deSugar/DsGRHSs.hs??compiler/deSugar/DsListComp.hs??compiler/deSugar/DsMonad.hs??compiler/deSugar/DsUtils.hs??compiler/deSugar/Match.hs??compiler/deSugar/MatchCon.hs??compiler/deSugar/MatchLit.hs??compiler/hsSyn/HsBinds.hs??compiler/hsSyn/HsDecls.hs??compiler/hsSyn/HsDoc.hs??compiler/hsSyn/HsExpr.hs??compiler/hsSyn/HsImpExp.hs??compiler/hsSyn/HsLit.hs??compiler/hsSyn/PlaceHolder.hs??compiler/hsSyn/HsPat.hs??compiler/hsSyn/HsSyn.hs??compiler/hsSyn/HsTypes.hs??compiler/hsSyn/HsUtils.hs??compiler/iface/BinIface.hs??compiler/iface/BuildTyCl.hs??compiler/iface/IfaceEnv.hs??compiler/iface/IfaceSyn.hs??compiler/iface/IfaceType.hs??compiler/iface/LoadIface.hs??compiler/iface/MkIface.hs??compiler/iface/TcIface.hs??compiler/iface/FlagChecker.hs??compiler/main/Annotations.hs??compiler/main/CmdLineParser.hs??compiler/main/CodeOutput.hs??compiler/stage1/build/Config.hs??compiler/main/Constants.hs??compiler/main/DriverMkDepend.hs??compiler/main/DriverPhases.hs??compiler/main/PipelineMonad.hs??compiler/main/DriverPipeline.hs??compiler/main/DynFlags.hs??compiler/main/ErrUtils.hs??compiler/main/Finder.hs??compiler/main/GHC.hs??compiler/main/GhcMake.hs??compiler/main/GhcPlugins.hs??compiler/main/DynamicLoading.hs??compiler/main/HeaderInfo.hs??compiler/main/HscMain.hs??compiler/main/HscStats.hs??compiler/main/HscTypes.hs??compiler/main/InteractiveEval.hs??compiler/main/InteractiveEvalTypes.hs??compiler/main/PackageConfig.hs??compiler/main/Packages.hs??compiler/main/PlatformConstants.hs??compiler/main/Plugins.hs??compiler/typecheck/TcPluginM.hs??compiler/main/PprTyThing.hs??compiler/main/StaticFlags.hs??compiler/deSugar/StaticPtrTable.hs??compiler/main/SysTools.hs??compiler/main/Elf.hs??compiler/main/TidyPgm.hs??compiler/parser/Ctype.hs??compiler/parser/HaddockUtils.hs??compiler/parser/Lexer.hs??compiler/types/OptCoercion.hs??compiler/parser/Parser.hs??compiler/parser/RdrHsSyn.hs??compiler/parser/ApiAnnotation.hs??compiler/prelude/ForeignCall.hs??compiler/prelude/PrelInfo.hs??compiler/prelude/PrelNames.hs??compiler/prelude/PrelRules.hs??compiler/prelude/PrimOp.hs??compiler/prelude/TysPrim.hs??compiler/prelude/TysWiredIn.hs??compiler/profiling/CostCentre.hs??compiler/profiling/ProfInit.hs??compiler/profiling/SCCfinal.hs??compiler/rename/RnBinds.hs??compiler/rename/RnEnv.hs??compiler/rename/RnExpr.hs??compiler/rename/RnHsDoc.hs??compiler/rename/RnNames.hs??compiler/rename/RnPat.hs??compiler/rename/RnSource.hs??compiler/rename/RnSplice.hs??compiler/rename/RnTypes.hs??compiler/simplCore/CoreMonad.hs??compiler/simplCore/CSE.hs??compiler/simplCore/FloatIn.hs??compiler/simplCore/FloatOut.hs??compiler/simplCore/LiberateCase.hs??compiler/simplCore/OccurAnal.hs??compiler/simplCore/SAT.hs??compiler/simplCore/SetLevels.hs??compiler/simplCore/SimplCore.hs??compiler/simplCore/SimplEnv.hs??compiler/simplCore/SimplMonad.hs??compiler/simplCore/SimplUtils.hs??compiler/simplCore/Simplify.hs??compiler/simplStg/SimplStg.hs??compiler/simplStg/StgStats.hs??compiler/simplStg/UnariseStg.hs??compiler/specialise/Rules.hs??compiler/specialise/SpecConstr.hs??compiler/specialise/Specialise.hs??compiler/stgSyn/CoreToStg.hs??compiler/stgSyn/StgLint.hs??compiler/stgSyn/StgSyn.hs??compiler/simplCore/CallArity.hs??compiler/stranal/DmdAnal.hs??compiler/stranal/WorkWrap.hs??compiler/stranal/WwLib.hs??compiler/typecheck/FamInst.hs??compiler/typecheck/Inst.hs??compiler/typecheck/TcAnnotations.hs??compiler/typecheck/TcArrows.hs??compiler/typecheck/TcBinds.hs??compiler/typecheck/TcClassDcl.hs??compiler/typecheck/TcDefaults.hs??compiler/typecheck/TcDeriv.hs??compiler/typecheck/TcEnv.hs??compiler/typecheck/TcExpr.hs??compiler/typecheck/TcForeign.hs??compiler/typecheck/TcGenDeriv.hs??compiler/typecheck/TcGenGenerics.hs??compiler/typecheck/TcHsSyn.hs??compiler/typecheck/TcHsType.hs??compiler/typecheck/TcInstDcls.hs??compiler/typecheck/TcMType.hs??compiler/typecheck/TcValidity.hs??compiler/typecheck/TcMatches.hs??compiler/typecheck/TcPat.hs??compiler/typecheck/TcPatSyn.hs??compiler/typecheck/TcRnDriver.hs??compiler/typecheck/TcRnMonad.hs??compiler/typecheck/TcRnTypes.hs??compiler/typecheck/TcRules.hs??compiler/typecheck/TcSimplify.hs??compiler/typecheck/TcErrors.hs??compiler/typecheck/TcTyClsDecls.hs??compiler/typecheck/TcTyDecls.hs??compiler/typecheck/TcTypeable.hs??compiler/typecheck/TcType.hs??compiler/typecheck/TcEvidence.hs??compiler/typecheck/TcUnify.hs??compiler/typecheck/TcInteract.hs??compiler/typecheck/TcCanonical.hs??compiler/typecheck/TcFlatten.hs??compiler/typecheck/TcSMonad.hs??compiler/typecheck/TcTypeNats.hs??compiler/typecheck/TcSplice.hs??compiler/types/Class.hs??compiler/types/Coercion.hs??compiler/deSugar/DsMeta.hs??compiler/prelude/THNames.hs??compiler/types/FamInstEnv.hs??compiler/typecheck/FunDeps.hs??compiler/types/InstEnv.hs??compiler/types/TyCon.hs??compiler/types/CoAxiom.hs??compiler/types/Kind.hs??compiler/types/Type.hs??compiler/types/TyCoRep.hs??compiler/types/Unify.hs??compiler/utils/Bag.hs??compiler/utils/Binary.hs??compiler/utils/BooleanFormula.hs??compiler/utils/BufWrite.hs??compiler/utils/Digraph.hs??compiler/utils/Encoding.hs??compiler/utils/FastFunctions.hs??compiler/utils/FastMutInt.hs??compiler/utils/FastString.hs??compiler/utils/FastStringEnv.hs??compiler/stage1/build/Fingerprint.hs??compiler/utils/FiniteMap.hs??compiler/utils/FV.hs??compiler/utils/GraphBase.hs??compiler/utils/GraphColor.hs??compiler/utils/GraphOps.hs??compiler/utils/GraphPpr.hs??compiler/utils/IOEnv.hs??compiler/utils/ListSetOps.hs??compiler/utils/Maybes.hs??compiler/utils/MonadUtils.hs??compiler/utils/OrdList.hs??compiler/utils/Outputable.hs??compiler/utils/Pair.hs??compiler/utils/Panic.hs??compiler/utils/Pretty.hs??compiler/utils/State.hs??compiler/utils/Stream.hs??compiler/utils/StringBuffer.hs??compiler/utils/UniqDFM.hs??compiler/utils/UniqDSet.hs??compiler/utils/UniqFM.hs??compiler/utils/UniqSet.hs??compiler/utils/Util.hs??compiler/vectorise/Vectorise/Builtins/Base.hs??compiler/vectorise/Vectorise/Builtins/Initialise.hs??compiler/vectorise/Vectorise/Builtins.hs??compiler/vectorise/Vectorise/Monad/Base.hs??compiler/vectorise/Vectorise/Monad/Naming.hs??compiler/vectorise/Vectorise/Monad/Local.hs??compiler/vectorise/Vectorise/Monad/Global.hs??compiler/vectorise/Vectorise/Monad/InstEnv.hs??compiler/vectorise/Vectorise/Monad.hs??compiler/vectorise/Vectorise/Utils/Base.hs??compiler/vectorise/Vectorise/Utils/Closure.hs??compiler/vectorise/Vectorise/Utils/Hoisting.hs??compiler/vectorise/Vectorise/Utils/PADict.hs??compiler/vectorise/Vectorise/Utils/Poly.hs??compiler/vectorise/Vectorise/Utils.hs??compiler/vectorise/Vectorise/Generic/Description.hs??compiler/vectorise/Vectorise/Generic/PAMethods.hs??compiler/vectorise/Vectorise/Generic/PADict.hs??compiler/vectorise/Vectorise/Generic/PData.hs??compiler/vectorise/Vectorise/Type/Env.hs??compiler/vectorise/Vectorise/Type/Type.hs??compiler/vectorise/Vectorise/Type/TyConDecl.hs??compiler/vectorise/Vectorise/Type/Classify.hs??compiler/vectorise/Vectorise/Convert.hs??compiler/vectorise/Vectorise/Vect.hs??compiler/vectorise/Vectorise/Var.hs??compiler/vectorise/Vectorise/Env.hs??compiler/vectorise/Vectorise/Exp.hs??compiler/vectorise/Vectorise.hs??compiler/cmm/Hoopl/Dataflow.hs??compiler/cmm/Hoopl.hs??compiler/nativeGen/AsmCodeGen.hs??compiler/nativeGen/TargetReg.hs??compiler/nativeGen/NCGMonad.hs??compiler/nativeGen/Instruction.hs??compiler/nativeGen/Format.hs??compiler/nativeGen/Reg.hs??compiler/nativeGen/RegClass.hs??compiler/nativeGen/PIC.hs??compiler/utils/Platform.hs??compiler/nativeGen/CPrim.hs??compiler/nativeGen/X86/Regs.hs??compiler/nativeGen/X86/RegInfo.hs??compiler/nativeGen/X86/Instr.hs??compiler/nativeGen/X86/Cond.hs??compiler/nativeGen/X86/Ppr.hs??compiler/nativeGen/X86/CodeGen.hs??compiler/nativeGen/PPC/Regs.hs??compiler/nativeGen/PPC/RegInfo.hs??compiler/nativeGen/PPC/Instr.hs??compiler/nativeGen/PPC/Cond.hs??compiler/nativeGen/PPC/Ppr.hs??compiler/nativeGen/PPC/CodeGen.hs??compiler/nativeGen/SPARC/Base.hs??compiler/nativeGen/SPARC/Regs.hs??compiler/nativeGen/SPARC/Imm.hs??compiler/nativeGen/SPARC/AddrMode.hs??compiler/nativeGen/SPARC/Cond.hs??compiler/nativeGen/SPARC/Instr.hs??compiler/nativeGen/SPARC/Stack.hs??compiler/nativeGen/SPARC/ShortcutJump.hs??compiler/nativeGen/SPARC/Ppr.hs??compiler/nativeGen/SPARC/CodeGen.hs??compiler/nativeGen/SPARC/CodeGen/Amode.hs??compiler/nativeGen/SPARC/CodeGen/Base.hs??compiler/nativeGen/SPARC/CodeGen/CondCode.hs??compiler/nativeGen/SPARC/CodeGen/Gen32.hs??compiler/nativeGen/SPARC/CodeGen/Gen64.hs??compiler/nativeGen/SPARC/CodeGen/Sanity.hs??compiler/nativeGen/SPARC/CodeGen/Expand.hs??compiler/nativeGen/RegAlloc/Liveness.hs??compiler/nativeGen/RegAlloc/Graph/Main.hs??compiler/nativeGen/RegAlloc/Graph/Stats.hs??compiler/nativeGen/RegAlloc/Graph/ArchBase.hs??compiler/nativeGen/RegAlloc/Graph/ArchX86.hs??compiler/nativeGen/RegAlloc/Graph/Coalesce.hs??compiler/nativeGen/RegAlloc/Graph/Spill.hs??compiler/nativeGen/RegAlloc/Graph/SpillClean.hs??compiler/nativeGen/RegAlloc/Graph/SpillCost.hs??compiler/nativeGen/RegAlloc/Graph/TrivColorable.hs??compiler/nativeGen/RegAlloc/Linear/Main.hs??compiler/nativeGen/RegAlloc/Linear/JoinToTargets.hs??compiler/nativeGen/RegAlloc/Linear/State.hs??compiler/nativeGen/RegAlloc/Linear/Stats.hs??compiler/nativeGen/RegAlloc/Linear/FreeRegs.hs??compiler/nativeGen/RegAlloc/Linear/StackMap.hs??compiler/nativeGen/RegAlloc/Linear/Base.hs??compiler/nativeGen/RegAlloc/Linear/X86/FreeRegs.hs??compiler/nativeGen/RegAlloc/Linear/X86_64/FreeRegs.hs??compiler/nativeGen/RegAlloc/Linear/PPC/FreeRegs.hs??compiler/nativeGen/RegAlloc/Linear/SPARC/FreeRegs.hs??compiler/nativeGen/Dwarf.hs??compiler/nativeGen/Dwarf/Types.hs??compiler/nativeGen/Dwarf/Constants.hs ghc: unrecognised flag: -this-unit-id unrecognised flag: -this-unit-id Usage: For basic information, try the `--help' option. https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=arm64&ver=8.0.0.20160204-1&stamp=1454952602 I didn?t quite follow the Cabal issues on the tickets list, so this might be known, but it certainly should not happen. Or is this a problem with 8.0.1-rc1 and I should just avoid that version somehow, and it will bootstrap with 8.0.1-rc2 just fine? 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 well-typed.com Tue Feb 9 08:58:01 2016 From: ben at well-typed.com (Ben Gamari) Date: Tue, 09 Feb 2016 09:58:01 +0100 Subject: [ANNOUNCE] GHC 8.0.1 release candidate 2 In-Reply-To: <1455007662.1636.3.camel@joachim-breitner.de> References: <8737t49yof.fsf@smart-cactus.org> <1455007662.1636.3.camel@joachim-breitner.de> Message-ID: <87a8na8dly.fsf@smart-cactus.org> Joachim Breitner writes: > Hi, > > Am Sonntag, den 07.02.2016, 19:13 +0100 schrieb Ben Gamari: >> As always, we look forward to hearing about any issues that you >> encounter with this candidate. Thanks to everyone who has contributed so >> far! > > I cannot bootstrap 8.0.1-rc2 with 8.0.1-rc1 > > unrecognised flag: -this-unit-id > > Usage: For basic information, try the `--help' option. > https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=arm64&ver=8.0.0.20160204-1&stamp=1454952602 > > > I didn?t quite follow the Cabal issues on the tickets list, so this > might be known, but it certainly should not happen. > > Or is this a problem with 8.0.1-rc1 and I should just avoid that > version somehow, and it will bootstrap with 8.0.1-rc2 just fine? > Yes, this should merely be a problem with -rc1. Edward Yang did some cleanups of the package-system command-line flags in -rc2. The original goal of this was to ensure that users with older Cabals aren't surprised with the terrible errors that they are currently faced with [1]. Sadly this didn't quite get resolved in -rc2, however. See D1892 [2] for one possible future direction for putting this issue to rest. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/ticket/11558 [2] https://phabricator.haskell.org/D1892 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From karel.gardas at centrum.cz Tue Feb 9 16:20:36 2016 From: karel.gardas at centrum.cz (Karel Gardas) Date: Tue, 09 Feb 2016 17:20:36 +0100 Subject: GHC build time graphs In-Reply-To: <87k2mtcozq.fsf@smart-cactus.org> References: <1454005734-sup-9633@sabre> <010A82CA-A36C-4739-ADFC-1B0035483351@iki.fi> <1454019988.2635.2.camel@joachim-breitner.de> <87k2mtcozq.fsf@smart-cactus.org> Message-ID: <56BA11D4.6050103@centrum.cz> On 01/28/16 11:34 PM, Ben Gamari wrote: > Joachim Breitner writes: > >> Hi Oleg, >> >> Am Freitag, den 29.01.2016, 00:22 +0200 schrieb Oleg Grenrus: >>> Is the same compiler used to build HEAD and 7.10,1? >> >> Good call. In fact, no: 7.10.1 is built with 7.6.3, while HEAD is built >> with 7.10.3. >> >> Anthony?s link, i.e. >> https://perf.haskell.org/ghc/#compare/ca00def1d7093d6b5b2a937ddfc8a01c152038eb/a496f82d5684f3025a60877600e82f0b29736e85 >> has links to the build logs of either build; there I could find that information. >> >> That might be (part) of the problem. But if it is, it is even worse, as >> it would mean not only building the compiler got slower, but the >> compiler itself... >> > I can verify that the build itself is indeed slower. Validating the > current state of ghc-7.10 takes 19 minutes, whereas ghc-8.0 takes 25.5 > minutes. This isn't entirely unexpected but the change is quite a bit > larger than I had thought. It would be nice to know which commits are > responsible. btw, just recent experience on ARM64 (X-gene board): bootstrapping 7.10.1 with 7.6.x took: ~120 minutes bootstrapping 8.0.1 RC2 with 7.10.1 took: ~446 minutes both run as: ./configure; time make -j8 although board is shared I've tried to look at it from time to time and have not observed anyone else there so I can assume this is indeed GHC slowness on unregisterised -fvia-C ports... Karel From conal at conal.net Wed Feb 10 02:47:38 2016 From: conal at conal.net (Conal Elliott) Date: Tue, 9 Feb 2016 18:47:38 -0800 Subject: Adding rules in a plugin? Message-ID: I'm writing a GHC plugin that generates new rules. The top-level identifier for the new rules' LHSs is always the same and is imported from another module. One of the arguments in the rule's LHSs, however, is defined in that module. I'm creating rules and adding them to the mg_rules of the module's ModGuts. I don't see them in the .hi files (viewed with "ghc --show-iface Foo.hi"), and they're not getting found in modules that import the modules where I'm trying to generate rules. Am I missing a crucial step? For instance, do I need also to use `addIdSpecialisations` with the argument identifiers, and if so, need I replace all instances of those identifiers in the module or just some of them? Thanks, -- Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: From conal at conal.net Wed Feb 10 18:17:04 2016 From: conal at conal.net (Conal Elliott) Date: Wed, 10 Feb 2016 10:17:04 -0800 Subject: Adding rules in a plugin? In-Reply-To: References: Message-ID: More study of GHC source code answered my question: when I generate a rule, set ru_auto to False rather than True, so that findExternalRules won't delete the rule. On Tue, Feb 9, 2016 at 6:47 PM, Conal Elliott wrote: > I'm writing a GHC plugin that generates new rules. The top-level > identifier for the new rules' LHSs is always the same and is imported from > another module. One of the arguments in the rule's LHSs, however, is > defined in that module. I'm creating rules and adding them to the mg_rules > of the module's ModGuts. I don't see them in the .hi files (viewed with > "ghc --show-iface Foo.hi"), and they're not getting found in modules that > import the modules where I'm trying to generate rules. Am I missing a > crucial step? For instance, do I need also to use `addIdSpecialisations` > with the argument identifiers, and if so, need I replace all instances of > those identifiers in the module or just some of them? > > > Thanks, -- Conal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magesh85 at gmail.com Thu Feb 11 07:41:10 2016 From: magesh85 at gmail.com (Magesh B) Date: Thu, 11 Feb 2016 13:11:10 +0530 Subject: Making a core app with a function having context in core2core plugin? Message-ID: Hi GHC Devs, Is it possible to make a core app with a function having contexts? For example, let us take showable :: P.Show a => a -> String showable = P.show Say, I would like to app showable with (Just 'a') in the core, which requires the following code showable @ (Maybe Char) *($fShowMaybe @ Char $fShowChar)* (Just @ Char (C# 'a')) But I couldn't find a way to construct the dictionary required by showable function myself in the core. Is there any ghc api using which I can get the required dictionary for a particular type (in the above case, Dictionary for Show instance of Maybe Char). Regards, Magesh B -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Feb 11 10:59:43 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 11 Feb 2016 10:59:43 +0000 Subject: Adding rules in a plugin? In-Reply-To: References: Message-ID: <5b684069b2154273bfab79c6428d1582@DB4PR30MB030.064d.mgd.msft.net> Correct. I?ve added more comments. From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Conal Elliott Sent: 10 February 2016 18:17 To: ghc-devs at haskell.org Subject: Re: Adding rules in a plugin? More study of GHC source code answered my question: when I generate a rule, set ru_auto to False rather than True, so that findExternalRules won't delete the rule. On Tue, Feb 9, 2016 at 6:47 PM, Conal Elliott > wrote: I'm writing a GHC plugin that generates new rules. The top-level identifier for the new rules' LHSs is always the same and is imported from another module. One of the arguments in the rule's LHSs, however, is defined in that module. I'm creating rules and adding them to the mg_rules of the module's ModGuts. I don't see them in the .hi files (viewed with "ghc --show-iface Foo.hi"), and they're not getting found in modules that import the modules where I'm trying to generate rules. Am I missing a crucial step? For instance, do I need also to use `addIdSpecialisations` with the argument identifiers, and if so, need I replace all instances of those identifiers in the module or just some of them? Thanks, -- Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: From takenobu.hs at gmail.com Thu Feb 11 12:19:03 2016 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Thu, 11 Feb 2016 21:19:03 +0900 Subject: [Haskell-cafe] Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic) In-Reply-To: References: <56B4CA58.4050101@htwk-leipzig.de> <56B4CCEB.5060406@htwk-leipzig.de> <20160205162651.GA28854@weber> <6B40AE7F-84DE-48A2-83FF-1940786CFC1F@cis.upenn.edu> <56B6097C.1010500@ro-che.info> Message-ID: Hi, I understood one more point. (I share here.) The Prelude library document for ghc 8.0 is already well described for beginners/newcomers. * The ($)'s signature of 8.0.1 is already simple (not include forall ...). * The Bool's kind of 8.0.1 is already represented with "TYPE Lifted" (changed from '*'). ghc7.8.4 [1]: data Bool :: * foldr :: (a -> b -> b) -> b -> [a] -> b ($) :: (a -> b) -> a -> b ghc7.10.4 [2]: data Bool :: * foldr :: (a -> b -> b) -> b -> t a -> b ($) :: (a -> b) -> a -> b ghc8.0.1-rc2 [3]: data Bool :: TYPE Lifted foldr :: (a -> b -> b) -> b -> t a -> b ($) :: (a -> b) -> a -> b [1] https://downloads.haskell.org/~ghc/7.8.4/docs/html/libraries/base-4.7.0.2/Prelude.html [2] https://downloads.haskell.org/~ghc/latest/docs/html/libraries/base-4.8.2.0/Prelude.html [3] https://downloads.haskell.org/~ghc/8.0.1-rc2/docs/html/libraries/base-4.9.0.0/Prelude.html Regards, Takenobu 2016-02-08 19:08 GMT+09:00 Takenobu Tani : > Hi Richard and devs, > > What a wonderful (#11549) ! > This is a beautiful solution for beginners/newcomers. > Beginners will not confuse and they can gradually go ahead. > > I extremely appreciate that you are continuously improving the ghc for us. > > Thank you very much, > Takenobu > > > 2016-02-07 0:17 GMT+09:00 Richard Eisenberg : > >> I have made a ticket #11549 ( >> https://ghc.haskell.org/trac/ghc/ticket/11549) requesting a >> -fshow-runtime-rep flag (recalling that the name levity will soon be >> outdated) as described in this thread. I will make sure this gets in for >> the release of 8.0. >> >> Other points: >> >> - You're quite right that (.) could be generalized. But I'll wait for >> someone to really want this. >> >> - I don't have a non-contrived example of the use of ($) with unlifted >> types. It's quite possible that when adding the dirty runST hack, it was >> observed that an unlifted type would be OK. At that point, the type of ($) >> didn't need to become so elaborate. And now we're just trying not to change >> old (but perhaps unrequested) behavior. >> >> - For the record, this debate is entirely unrelated to the runST >> impredicativity hack. (Except, as noted above, perhaps in history.) That >> hack remains, basically unchanged. >> >> - On Feb 6, 2016, at 9:55 AM, Roman Cheplyaka wrote: >> > >> > I would call this a simplification rather than a lie. >> >> This is a very convincing argument. >> >> - Thanks, also, for the voice of support. What I love about the Haskell >> community is that we can have an impassioned debate full of strong >> opinions, and it all very rarely devolves into a proper flame war. All the >> posts I've seen in this thread have been constructive and helpful. Thanks. >> >> Richard >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Thu Feb 11 12:33:09 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 11 Feb 2016 13:33:09 +0100 Subject: [Haskell-cafe] Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic) In-Reply-To: References: <56B4CA58.4050101@htwk-leipzig.de> <56B4CCEB.5060406@htwk-leipzig.de> <20160205162651.GA28854@weber> <6B40AE7F-84DE-48A2-83FF-1940786CFC1F@cis.upenn.edu> <56B6097C.1010500@ro-che.info> Message-ID: <87twlf8m0q.fsf@smart-cactus.org> Takenobu Tani writes: > Hi, > > I understood one more point. (I share here.) > The Prelude library document for ghc 8.0 is already well described for > beginners/newcomers. > > * The ($)'s signature of 8.0.1 is already simple (not include forall ...). > * The Bool's kind of 8.0.1 is already represented with "TYPE Lifted" > (changed from '*'). > > > ghc7.8.4 [1]: > > data Bool :: * > foldr :: (a -> b -> b) -> b -> [a] -> b > ($) :: (a -> b) -> a -> b > > > ghc7.10.4 [2]: > > data Bool :: * > foldr :: (a -> b -> b) -> b -> t a -> b > ($) :: (a -> b) -> a -> b > > > ghc8.0.1-rc2 [3]: > > data Bool :: TYPE Lifted To clarify, this isn't actually a change; `*` is merely a synonym for `TYPE 'Lifted`. Moreover, I believe this is a bug. In general we should continue to show `*` for plain lifted types. If you look at other types in the -rc2 haddocks you will see that they are indeed rendered as they were in previous releases, with no kind annotation at all. Bool is likely only rendered differently as it is a wired-in type; we'll need to fix this. I've opened #11567 to track this issue. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From takenobu.hs at gmail.com Thu Feb 11 13:47:26 2016 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Thu, 11 Feb 2016 22:47:26 +0900 Subject: [Haskell-cafe] Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic) In-Reply-To: <87twlf8m0q.fsf@smart-cactus.org> References: <56B4CA58.4050101@htwk-leipzig.de> <56B4CCEB.5060406@htwk-leipzig.de> <20160205162651.GA28854@weber> <6B40AE7F-84DE-48A2-83FF-1940786CFC1F@cis.upenn.edu> <56B6097C.1010500@ro-che.info> <87twlf8m0q.fsf@smart-cactus.org> Message-ID: Hi Ben, Thank you for explanation. Sorry, I was misunderstood that ghc8 changes representation of '*'. (In addition to the Bool, but also Int, Float,..) There are also followings: Alternative f => Monoid (Alt (TYPE Lifted) f a) Functor (Proxy (TYPE Lifted)) Foldable (Const (TYPE Lifted) m) Thank you very much, Takenobu 2016-02-11 21:33 GMT+09:00 Ben Gamari : > Takenobu Tani writes: > > > Hi, > > > > I understood one more point. (I share here.) > > The Prelude library document for ghc 8.0 is already well described for > > beginners/newcomers. > > > > * The ($)'s signature of 8.0.1 is already simple (not include forall > ...). > > * The Bool's kind of 8.0.1 is already represented with "TYPE Lifted" > > (changed from '*'). > > > > > > ghc7.8.4 [1]: > > > > data Bool :: * > > foldr :: (a -> b -> b) -> b -> [a] -> b > > ($) :: (a -> b) -> a -> b > > > > > > ghc7.10.4 [2]: > > > > data Bool :: * > > foldr :: (a -> b -> b) -> b -> t a -> b > > ($) :: (a -> b) -> a -> b > > > > > > ghc8.0.1-rc2 [3]: > > > > data Bool :: TYPE Lifted > > To clarify, this isn't actually a change; `*` is merely a synonym for > `TYPE 'Lifted`. > > Moreover, I believe this is a bug. In general we should continue to show > `*` for plain lifted types. If you look at other types in the -rc2 > haddocks you will see that they are indeed rendered as they were in > previous releases, with no kind annotation at all. Bool is likely only > rendered differently as it is a wired-in type; we'll need to fix this. > I've opened #11567 to track this issue. > > Cheers, > > - Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.stolarek at p.lodz.pl Fri Feb 12 07:36:56 2016 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Fri, 12 Feb 2016 08:36:56 +0100 Subject: GHC performance dashboard question Message-ID: <201602120836.56703.jan.stolarek@p.lodz.pl> Joachim, what do I need to do to have my wip/ branch picked up by the performance dashboard? I'm thinking about branch wip/js-hoopl-cleanup, which was pushed yesterday but still hasn't been measured for performance. 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 dominikbollmann at gmail.com Fri Feb 12 17:17:31 2016 From: dominikbollmann at gmail.com (Dominik Bollmann) Date: Fri, 12 Feb 2016 18:17:31 +0100 Subject: [Template Haskell] Desugaring TH brackets vs. Desugaring normal HsExprS. Message-ID: <87pow17sr8.fsf@t450s.i-did-not-set--mail-host-address--so-tickle-me> Hi, I'm currently trying to understand GHC's implementation of Template Haskell and I've had the following two questions when reading upon deSugar/DsMeta.hs and deSugar/dsExpr.hs (disclaimer: I'm a complete newbie to GHC and do not know pretty much anything about its internals; so please excuse silly questions). 1) As far as I understand DsMeta, its purpose is to desugar the contents of TH quotation brackets, e.g. [| \x -> x |]. Given the HsExpr contents, say `expr`, of a quotation bracket, it creates a CoreExpr /representation/ of `expr` such that /evaluating/ this CoreExpr representation yields a TH expression equivalent to `expr`. (This is similar to how quotations are implemented in the original TH paper). On the other hand, when instead writing the above TH quote, (i.e., [| \x -> x |]), explicitly as newName "x" >>= (\x -> lamE (varP x) (varE x)) (*) there is no need to build a CoreExpr /representation/ because we already got the TH value we're interested in; Hence, in this case DsExpr desugars the above (*) directly to a CoreExpr that represents it. Is my understanding of the above correct? I tried to confirm it using the following to splices: test1 :: Q Exp test1 = [| \x -> x |] test2 :: Q Exp test2 = do x <- newName "x" lamE [(varP x)] (varE x) However, dumping the desugared output of these splices using `-ddump-ds` gives the exact same CoreExprS: test1 :: Q Exp [LclIdX, Str=DmdType] test1 = Language.Haskell.TH.Syntax.bindQ @ Name @ Exp (newName (GHC.CString.unpackCString# "x"#)) (\ (x_a399 :: Name) -> lamE (GHC.Types.: @ PatQ (varP x_a399) (GHC.Types.[] @ PatQ)) (varE x_a399)) test2 :: Q Exp [LclIdX, Str=DmdType] test2 = >>= @ Q Language.Haskell.TH.Syntax.$fMonadQ @ Name @ Exp (newName (GHC.CString.unpackCString# "x"#)) (\ (x_a39a :: Name) -> lamE (GHC.Types.: @ PatQ (varP x_a39a) (GHC.Types.[] @ PatQ)) (varE x_a39a)) Could anyone explain to me why both CoreExpr dumps are the same? Shouldn't the first be a /representation/ that, only when run, yields the second CoreExpr? If anyone could help me understanding this, it'd be great! Thanks, Dominik. From simonpj at microsoft.com Fri Feb 12 17:37:51 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 12 Feb 2016 17:37:51 +0000 Subject: Validation failures Message-ID: <36f3e94d189e4c048c6cdb9ca19263d3@DB4PR30MB030.064d.mgd.msft.net> I?m getting this on a clean HEAD. Is anyone else? Simon Unexpected stat failures: perf/compiler T5030 [stat not good enough] (normal) perf/compiler T9872b [stat not good enough] (normal) perf/compiler T9872c [stat not good enough] (normal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Fri Feb 12 18:30:00 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 12 Feb 2016 19:30:00 +0100 Subject: Validation failures In-Reply-To: <36f3e94d189e4c048c6cdb9ca19263d3@DB4PR30MB030.064d.mgd.msft.net> References: <36f3e94d189e4c048c6cdb9ca19263d3@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <87r3gh93yv.fsf@smart-cactus.org> Simon Peyton Jones writes: > I?m getting this on a clean HEAD. Is anyone else? > Simon > > Unexpected stat failures: > perf/compiler T5030 [stat not good enough] (normal) > perf/compiler T9872b [stat not good enough] (normal) > perf/compiler T9872c [stat not good enough] (normal) I suspect this may have been due to niteria's piResult patch. I noticed similar failures when attempting to merge his patch and meant to return to the matter but forgot leave a comment on the Diff. 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 Feb 12 18:44:45 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 12 Feb 2016 19:44:45 +0100 Subject: Validation failures In-Reply-To: <87r3gh93yv.fsf@smart-cactus.org> References: <36f3e94d189e4c048c6cdb9ca19263d3@DB4PR30MB030.064d.mgd.msft.net> <87r3gh93yv.fsf@smart-cactus.org> Message-ID: <87oabl93aa.fsf@smart-cactus.org> Ben Gamari writes: > Simon Peyton Jones writes: > >> I?m getting this on a clean HEAD. Is anyone else? >> Simon >> >> Unexpected stat failures: >> perf/compiler T5030 [stat not good enough] (normal) >> perf/compiler T9872b [stat not good enough] (normal) >> perf/compiler T9872c [stat not good enough] (normal) > > I suspect this may have been due to niteria's piResult patch. I noticed > similar failures when attempting to merge his patch and meant to return > to the matter but forgot leave a comment on the Diff. > In fact niteria reverted the patch in question so hopefully it these should now be gone. 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 Fri Feb 12 18:59:53 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 12 Feb 2016 19:59:53 +0100 Subject: GHC performance dashboard question In-Reply-To: <201602120836.56703.jan.stolarek@p.lodz.pl> References: <201602120836.56703.jan.stolarek@p.lodz.pl> Message-ID: <1455303593.3543.1.camel@joachim-breitner.de> Hi Janek, Am Freitag, den 12.02.2016, 08:36 +0100 schrieb Jan Stolarek: > Joachim, what do I need to do to have my wip/ branch picked up by the > performance dashboard? I'm? > thinking about branch wip/js-hoopl-cleanup, which was pushed > yesterday but still hasn't been? > measured for performance. wip/ branches have lower precedence than the master branch, so in busy times, it just takes a while. But by now, the branch has been measured. But no noticable change: https://perf.haskell.org/ghc/#compare/c6485d5e6daec20c8ff66d6e721d3e0a5f3156ac/a1931b9f28b1b44cc67b1666719db5ff46ee19ef Greetings, Joachim --? -- Joachim ?nomeata? Breitner ? mail at joachim-breitner.de ? https://www.joachim-breitner.de/ ? XMPP: nomeata at joachim-breitner.de?? OpenPGP-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 eir at cis.upenn.edu Fri Feb 12 19:04:21 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 12 Feb 2016 14:04:21 -0500 Subject: quick performance measurements Message-ID: <5A53015C-3260-461D-826E-18F85903C289@cis.upenn.edu> Hi devs, I have a few ideas for tweaks to improve compiler performance. (For example, reversing the order of comparisons in a short-circuiting comparison operation.) I don't have a particular test case with a profile that tells me where the smoking gun is. But I'd like to try these easy tweaks just to see if performance improves. My question: Is there an easy way to run some command that will give me helpful feedback on my performance tweak? Of course, I could push to a branch and have perf.haskell.org tell me. But that takes a long time. I could compile a few files and examine the output manually. But that's a bit painful. Ideally, there would be a way to run a portion of the testsuite and have the testsuite tool aggregate performance characteristics and report. Or perhaps there's a way to get cabal to aggregate performance characteristics, and I could just try compiling a few libraries. Any ideas out there? Thanks! Richard From rwbarton at gmail.com Fri Feb 12 20:02:30 2016 From: rwbarton at gmail.com (Reid Barton) Date: Fri, 12 Feb 2016 15:02:30 -0500 Subject: GHC build time graphs In-Reply-To: <56BA11D4.6050103@centrum.cz> References: <1454005734-sup-9633@sabre> <010A82CA-A36C-4739-ADFC-1B0035483351@iki.fi> <1454019988.2635.2.camel@joachim-breitner.de> <87k2mtcozq.fsf@smart-cactus.org> <56BA11D4.6050103@centrum.cz> Message-ID: On Tue, Feb 9, 2016 at 11:20 AM, Karel Gardas wrote: > On 01/28/16 11:34 PM, Ben Gamari wrote: > >> Joachim Breitner writes: >> >> Hi Oleg, >>> >>> Am Freitag, den 29.01.2016, 00:22 +0200 schrieb Oleg Grenrus: >>> >>>> Is the same compiler used to build HEAD and 7.10,1? >>>> >>> >>> Good call. In fact, no: 7.10.1 is built with 7.6.3, while HEAD is built >>> with 7.10.3. >>> >>> Anthony?s link, i.e. >>> >>> https://perf.haskell.org/ghc/#compare/ca00def1d7093d6b5b2a937ddfc8a01c152038eb/a496f82d5684f3025a60877600e82f0b29736e85 >>> has links to the build logs of either build; there I could find that >>> information. >>> >>> That might be (part) of the problem. But if it is, it is even worse, as >>> it would mean not only building the compiler got slower, but the >>> compiler itself... >>> >>> I can verify that the build itself is indeed slower. Validating the >> current state of ghc-7.10 takes 19 minutes, whereas ghc-8.0 takes 25.5 >> minutes. This isn't entirely unexpected but the change is quite a bit >> larger than I had thought. It would be nice to know which commits are >> responsible. >> > > btw, just recent experience on ARM64 (X-gene board): > > bootstrapping 7.10.1 with 7.6.x took: ~120 minutes > bootstrapping 8.0.1 RC2 with 7.10.1 took: ~446 minutes > > both run as: ./configure; time make -j8 > It would be interesting to have the time for bootstrapping 7.10.1 with 7.10.1 too, for comparison. Regards, Reid Barton -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Feb 12 20:28:34 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 12 Feb 2016 20:28:34 +0000 Subject: quick performance measurements In-Reply-To: <5A53015C-3260-461D-826E-18F85903C289@cis.upenn.edu> References: <5A53015C-3260-461D-826E-18F85903C289@cis.upenn.edu> Message-ID: <33b940420a5b4476bdc5b389f8d86118@DB4PR30MB030.064d.mgd.msft.net> cd testsuite/tests/perf; make | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Richard | Eisenberg | Sent: 12 February 2016 19:04 | To: ghc-devs at haskell.org developers | Subject: quick performance measurements | | Hi devs, | | I have a few ideas for tweaks to improve compiler performance. (For example, | reversing the order of comparisons in a short-circuiting comparison | operation.) I don't have a particular test case with a profile that tells me | where the smoking gun is. But I'd like to try these easy tweaks just to see | if performance improves. | | My question: | Is there an easy way to run some command that will give me helpful feedback | on my performance tweak? | | Of course, I could push to a branch and have | https://na01.safelinks.protection.outlook.com/?url=perf.haskell.org&data=01%7 | c01%7csimonpj%40064d.mgd.microsoft.com%7cb2e1edc8a6f248a9066508d333df5623%7c7 | 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=wU6DNmX%2bLF8sagU0B9yJAh4MKJ3yJc1CA | omIiSI%2fqvM%3d tell me. But that takes a long time. I could compile a few | files and examine the output manually. But that's a bit painful. Ideally, | there would be a way to run a portion of the testsuite and have the testsuite | tool aggregate performance characteristics and report. Or perhaps there's a | way to get cabal to aggregate performance characteristics, and I could just | try compiling a few libraries. Any ideas out there? | | Thanks! | Richard | _______________________________________________ | 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%7cb2e1edc8a6f248a9066508 | d333df5623%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=JnjGw%2fk%2brdNGy9VNY | 0m1KA7Ojr2ubJO6PneeGVL4LmY%3d From eir at cis.upenn.edu Fri Feb 12 20:30:19 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 12 Feb 2016 15:30:19 -0500 Subject: quick performance measurements In-Reply-To: <33b940420a5b4476bdc5b389f8d86118@DB4PR30MB030.064d.mgd.msft.net> References: <5A53015C-3260-461D-826E-18F85903C289@cis.upenn.edu> <33b940420a5b4476bdc5b389f8d86118@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <28833279-4E21-4DB2-B9A9-440C58BA8230@cis.upenn.edu> On Feb 12, 2016, at 3:28 PM, Simon Peyton Jones wrote: > cd testsuite/tests/perf; make But that tells me only about failures. What if I have a tweak that makes an average 1% improvement over lots of files? That would be a nice improvement, but we don't have an easy way to collect this info, I think, other than perf.haskell.org. From thomasmiedema at gmail.com Fri Feb 12 20:38:40 2016 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Fri, 12 Feb 2016 21:38:40 +0100 Subject: quick performance measurements In-Reply-To: <28833279-4E21-4DB2-B9A9-440C58BA8230@cis.upenn.edu> References: <5A53015C-3260-461D-826E-18F85903C289@cis.upenn.edu> <33b940420a5b4476bdc5b389f8d86118@DB4PR30MB030.064d.mgd.msft.net> <28833279-4E21-4DB2-B9A9-440C58BA8230@cis.upenn.edu> Message-ID: You could tweak the function `checkStats` in `testsuite/driver/testlib.py` a bit, to not only report failures. Maybe also disable the following check, if you're doing this from a debug build: # Compiler performance numbers change when debugging is on, making the results # useless and confusing. Therefore, skip if debugging is on. if compiler_debugged(): skip(name, opts) On Fri, Feb 12, 2016 at 9:30 PM, Richard Eisenberg wrote: > > On Feb 12, 2016, at 3:28 PM, Simon Peyton Jones > wrote: > > > cd testsuite/tests/perf; make > > But that tells me only about failures. What if I have a tweak that makes > an average 1% improvement over lots of files? That would be a nice > improvement, but we don't have an easy way to collect this info, I think, > other than perf.haskell.org. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Fri Feb 12 20:48:31 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 12 Feb 2016 21:48:31 +0100 Subject: quick performance measurements In-Reply-To: <5A53015C-3260-461D-826E-18F85903C289@cis.upenn.edu> References: <5A53015C-3260-461D-826E-18F85903C289@cis.upenn.edu> Message-ID: <87k2m98xk0.fsf@smart-cactus.org> Richard Eisenberg writes: > Hi devs, > > I have a few ideas for tweaks to improve compiler performance. (For > example, reversing the order of comparisons in a short-circuiting > comparison operation.) I don't have a particular test case with a > profile that tells me where the smoking gun is. But I'd like to try > these easy tweaks just to see if performance improves. > > My question: Is there an easy way to run some command that will give > me helpful feedback on my performance tweak? > > Of course, I could push to a branch and have perf.haskell.org tell me. > But that takes a long time. I could compile a few files and examine > the output manually. But that's a bit painful. Ideally, there would be > a way to run a portion of the testsuite and have the testsuite tool > aggregate performance characteristics and report. Or perhaps there's a > way to get cabal to aggregate performance characteristics, and I could > just try compiling a few libraries. Any ideas out there? > Indeed I wish we had better infrastructure for this. There is nofib, which IIRC tracks compile-time performance although the coverage isn't terribly great. Otherwise, beyond tweaking the testsuite driver as thomie suggests the options are sadly fairly limited. 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 Fri Feb 12 21:31:26 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 12 Feb 2016 22:31:26 +0100 Subject: quick performance measurements In-Reply-To: <5A53015C-3260-461D-826E-18F85903C289@cis.upenn.edu> References: <5A53015C-3260-461D-826E-18F85903C289@cis.upenn.edu> Message-ID: <1455312686.3543.14.camel@joachim-breitner.de> Hi, Am Freitag, den 12.02.2016, 14:04 -0500 schrieb Richard Eisenberg: > Ideally, there would be a way to run a portion of the testsuite and > have the testsuite tool aggregate performance characteristics and > report. if you run the test suite with $?VERBOSE=4? you get the detailed stats for every perf test, not only for the failing ones. This is what the gipeda runner does. You?d still have to manually compare them, though; no aggregation happening. Also, the compiler perf test cases usually check one specific extreme code path, so they are not a good measure of real world performance. nofib is better there, and has comparing integrated, but only checks those parts of the compiler that deal with idiomatic Haskell code from 10 or 20 years back. Maybe I should write a text that explains how to run gipeda locally on a bunch of commits on a local branch... but it?s only making the results more shiny, not more significant, than running nofib or the test suite manually. Greetings, Joachim -- Joachim ?nomeata? Breitner ? mail at joachim-breitner.de ? https://www.joachim-breitner.de/ ? XMPP: nomeata at joachim-breitner.de?? OpenPGP-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 karel.gardas at centrum.cz Fri Feb 12 21:43:40 2016 From: karel.gardas at centrum.cz (Karel Gardas) Date: Fri, 12 Feb 2016 22:43:40 +0100 Subject: GHC build time graphs In-Reply-To: References: <1454005734-sup-9633@sabre> <010A82CA-A36C-4739-ADFC-1B0035483351@iki.fi> <1454019988.2635.2.camel@joachim-breitner.de> <87k2mtcozq.fsf@smart-cactus.org> <56BA11D4.6050103@centrum.cz> Message-ID: <56BE520C.6010005@centrum.cz> On 02/12/16 09:02 PM, Reid Barton wrote: > btw, just recent experience on ARM64 (X-gene board): > > bootstrapping 7.10.1 with 7.6.x took: ~120 minutes > bootstrapping 8.0.1 RC2 with 7.10.1 took: ~446 minutes > > both run as: ./configure; time make -j8 > > > It would be interesting to have the time for bootstrapping 7.10.1 with > 7.10.1 too, for comparison. Good idea, build is running, but is sluggish just from the first sight. Running already for 1h20m and still building stage1. This is more in line with 8.0.1 I'm afraid. Anyway, I'll update with proper time once it is at the end. Looks like I'll also need to do 7.8.x build to see where we are on this... Karel From cma at bitemyapp.com Sat Feb 13 08:32:32 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Sat, 13 Feb 2016 02:32:32 -0600 Subject: New type of expressions containing (error ...) includes noisy implicit parameter Message-ID: Prelude> let myList = [1, 2, 3 :: Integer] Prelude> let myList' = myList ++ undefined Prelude> :t myList myList :: [Integer] Prelude> :t myList' myList' :: (?callStack::GHC.Stack.Types.CallStack) => [Integer] This is on by default and insofar as I've been able to try, it's avoidable in a default GHCi 8.0 REPL session. I'm glad I caught this before our book goes to print in a couple months. We'd managed to avoid talking about implicit parameters in 1,100+ pages of book but now we're forced to acknowledge their existence in the 4th of 32 chapters. This slipped past the radar more stealthily than the earlier stages of BBP did for 7.10. I was hearing about BBP on the GHC Trac pretty early on for months on end. Was the thinking that people still used implicit parameters for anything or taught them? On the one hand, this is a nice change and something I personally attempted (and failed) to make easier in GHC 7.10. The implementation making the types noisy rankles and didn't seem necessary when I investigated it between 7.8 and 7.10. Could you warn us when (educationally relevant?) stuff like this is coming down the pipe before the RC please? Ideally during the design phase. I think this was discussed as part of FTP to avoid future debacles. This isn't just a pedagogical problem, this is a UX problem. The users don't _care_ that call stack information is being carried around. Why would they? It happens without any mention in the types in almost every other programming language. --- Chris Allen -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Sat Feb 13 09:25:29 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 13 Feb 2016 10:25:29 +0100 Subject: New type of expressions containing (error ...) includes noisy implicit parameter In-Reply-To: References: Message-ID: <87h9hd7yie.fsf@smart-cactus.org> Christopher Allen writes: > Prelude> let myList = [1, 2, 3 :: Integer] > Prelude> let myList' = myList ++ undefined > Prelude> :t myList > myList :: [Integer] > Prelude> :t myList' > myList' :: (?callStack::GHC.Stack.Types.CallStack) => [Integer] > ... > This isn't just a pedagogical problem, this is a UX problem. The users > don't _care_ that call stack information is being carried around. Why would > they? It happens without any mention in the types in almost every other > programming language. > Well, in the case of implicit call stacks users arguably *need* to care whether call stack information is carried around: you only get call stack information when you explicit request request one. This is one of the limitations of the implicit callstack mechanism. That being said, the example that you offer is a bit suspicious to the point where I suspect it's a bug. As far as I know, the solver should not introduce new callstack constraints: if a CallStack constraint doesn't exist in the available context the solver should simply satisfy it with an empty callstack and that should be the end of it (Eric, correct me if I'm wrong). Indeed, 7.10.2, which also had an early version of implicit callstack support, did exactly this. I haven't yet looked any further into what may have changed, but I have opened #11573 to track this. Thanks for pointing this out. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From matthewtpickering at gmail.com Sat Feb 13 11:50:39 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Sat, 13 Feb 2016 11:50:39 +0000 Subject: Potentially confusing syntax for injective type families Message-ID: I was updating haskell-src-exts for ghc 8.0 recently and found some of the syntax for injective type families quite confusing. Is it a problem that the two following snippets have quite different meanings? 1. With the infectivity annotation, this declares an associated type. class Hcl a b where type Ht a b = r | r -> b a 2. Without the infectivity annotation, this declares an associate type synonym default. This isn't valid because Ht is not declared as an associated type before hand and r is not mentioned on the LHS. class Hcl a b where type Ht a b = r Has this been considered? Matt From ben at smart-cactus.org Sat Feb 13 12:41:48 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 13 Feb 2016 13:41:48 +0100 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: References: Message-ID: <87egcg93zn.fsf@smart-cactus.org> Ryan Scott writes: > Hi Chris, > > The change to ($)'s type is indeed intentional. The short answer is > that ($)'s type prior to GHC 8.0 was lying a little bit. If you > defined something like this: > > unwrapInt :: Int -> Int# > unwrapInt (I# i) = i > ... Hello everyone, While this thread continues to smolder, it seems that the arguments relevant to the levity polymorphism change have been sussed out. Now seems like a good time to review what we have all learned, * In 7.10 and earlier the type of ($) is a bit of a lie as it did not reflect the fact that the result type was open-kinded. ($) also has magic to allow impredicative uses, although this is orthogonal to the present levity discussion. * the type of ($) has changed to become more truthful in 8.0: we now capture lifted-ness in the type system with the notion of Levity. * there is widespread belief that the new type is too noisy and obfuscates the rather simple concept embodied by ($). This is especially concerning for those teaching and learning the language. * One approach to fix this would be to specialize ($) for lifted types and introduce a new levity polymorphic variant. This carries the potential to break existing users of ($), although it's unclear how much code this would affect in practice. * Another approach would be to preserve the current lie with pretty-printer behavior. This would be relatively easy to do and would allow us to avoid breaking existing users of ($). This, however, comes at the expense of some potential confusion when polymorphism is needed. * There are further questions regarding the appropriate kinds of (->) and (.) [1] * Incidentally, there is a GHC or Haddock bug [2] which causes kind signatures to be unnecessarily shown in documentation for some types, exposing levities to the user. The current plan to address this situation is as follows, * Introduce [3] a flag, -fshow-runtime-rep, which when disabled will cause the pretty-printer to instantiate levity-polymorphic types as lifted (e.g. resulting in *). This flag will be off by default, meaning that users will in most cases see the usual lifted types unless they explicitly request otherwise. * Fix the GHC/Haddock bug, restoring elision of unnecessary kind signatures in documentation. * In the future we should seriously consider introducing an alternate Prelude for beginners As far as I can tell from the discussion, this was an acceptable solution to all involved. If there are any remaining objections or concerns let's discuss them in another thread. Thanks to everyone who contributed to this effort. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/ticket/10343#comment:27 [2] https://ghc.haskell.org/trac/ghc/ticket/11567 [3] https://ghc.haskell.org/trac/ghc/ticket/11549 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From shumovichy at gmail.com Sat Feb 13 16:40:09 2016 From: shumovichy at gmail.com (Yuras Shumovich) Date: Sat, 13 Feb 2016 19:40:09 +0300 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: <87egcg93zn.fsf@smart-cactus.org> References: <87egcg93zn.fsf@smart-cactus.org> Message-ID: <1455381609.2134.16.camel@gmail.com> On Sat, 2016-02-13 at 13:41 +0100, Ben Gamari wrote: > Ryan Scott writes: > > > Hi Chris, > > > > The change to ($)'s type is indeed intentional. The short answer is > > that ($)'s type prior to GHC 8.0 was lying a little bit. If you > > defined something like this: > > > > ????unwrapInt :: Int -> Int# > > ????unwrapInt (I# i) = i > > > ... > > Hello everyone, > > While this thread continues to smolder, it seems that the arguments > relevant to the levity polymorphism change have been sussed out. Now > seems like a good time to review what we have all learned, > > ?* In 7.10 and earlier the type of ($) is a bit of a lie as it did > not > ???reflect the fact that the result type was open-kinded. > > ???($) also has magic to allow impredicative uses, although this is > ???orthogonal to the present levity discussion. > ??????? > ?* the type of ($) has changed to become more truthful in 8.0: we now > ???capture lifted-ness in the type system with the notion of Levity. > > ?* there is widespread belief that the new type is too noisy and > ???obfuscates the rather simple concept embodied by ($). This is > ???especially concerning for those teaching and learning the > language. > > ?* One approach to fix this would be to specialize ($) for lifted > types > ???and introduce a new levity polymorphic variant. This carries the > ???potential to break existing users of ($), although it's unclear > how > ???much code this would affect in practice. > > ?* Another approach would be to preserve the current lie with > ???pretty-printer behavior. This would be relatively easy to do and > ???would allow us to avoid breaking existing users of ($). This, > ???however, comes at the expense of some potential confusion when > ???polymorphism is needed. Thank you for the summary! The thread is too big to find anything in it. I'd like to present a bit different approach, kind of a compromise, without lie and code breakage: introduce a language pragma for levity polymorphism and default levity polymorphic signatures to "*" when the pragma is not enabled. For example, ($) could be defined like it is right now: ($) ? :: forall (w :: GHC.Types.Levity) a (b :: TYPE w). ? ? ?(a -> b) -> a -> b But when it is used in a module without levity polymorphism enabled, "w" is defaulted to "Lifted", "b" gets kind "*", and ($) gets its old type: ($) ? :: (a -> b) -> a -> b So any use of ($) with types on kind "#" is disallowed. But with levily polymorphism enabled, one will see the full type and use ($) with unlifted types. To prevent breakage of the existing code, MagicHash extension should by default imply levity polymorphism. What do you think? Am I missing something? Thanks, Yuras. > ?* There are further questions regarding the appropriate kinds > ???of (->) and (.) [1] > > ?* Incidentally, there is a GHC or Haddock bug [2] which causes kind > ???signatures to be unnecessarily shown in documentation for some > types, > ???exposing levities to the user. > > The current plan to address this situation is as follows, > > ?* Introduce [3] a flag, -fshow-runtime-rep, which when disabled will > ???cause the pretty-printer to instantiate levity-polymorphic types > as > ???lifted (e.g. resulting in *). This flag will be off by default, > ???meaning that users will in most cases see the usual lifted types > ???unless they explicitly request otherwise. > > ?* Fix the GHC/Haddock bug, restoring elision of unnecessary kind > ???signatures in documentation. > > ?* In the future we should seriously consider introducing an > alternate > ???Prelude for beginners > ? > As far as I can tell from the discussion, this was an acceptable > solution to all involved. If there are any remaining objections or > concerns let's discuss them in another thread. > > Thanks to everyone who contributed to this effort. > > Cheers, > > - Ben > > > [1] https://ghc.haskell.org/trac/ghc/ticket/10343#comment:27 > [2] https://ghc.haskell.org/trac/ghc/ticket/11567 > [3] https://ghc.haskell.org/trac/ghc/ticket/11549 > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From eric at seidel.io Sat Feb 13 16:54:01 2016 From: eric at seidel.io (Eric Seidel) Date: Sat, 13 Feb 2016 08:54:01 -0800 Subject: New type of expressions containing (error ...) includes noisy implicit parameter In-Reply-To: <87h9hd7yie.fsf@smart-cactus.org> References: <87h9hd7yie.fsf@smart-cactus.org> Message-ID: <1455382441.1805210.520289882.7F5B7E6A@webmail.messagingengine.com> On Sat, Feb 13, 2016, at 01:25, Ben Gamari wrote: > Christopher Allen writes: > > > Prelude> let myList = [1, 2, 3 :: Integer] > > Prelude> let myList' = myList ++ undefined > > Prelude> :t myList > > myList :: [Integer] > > Prelude> :t myList' > > myList' :: (?callStack::GHC.Stack.Types.CallStack) => [Integer] > > > ... > > This isn't just a pedagogical problem, this is a UX problem. The users > > don't _care_ that call stack information is being carried around. Why would > > they? It happens without any mention in the types in almost every other > > programming language. > > > Well, in the case of implicit call stacks users arguably *need* to care > whether call stack information is carried around: you only get call > stack information when you explicit request request one. This is one of > the limitations of the implicit callstack mechanism. > > That being said, the example that you offer is a bit suspicious to the > point where I suspect it's a bug. As far as I know, the solver should > not introduce new callstack constraints: if a CallStack constraint > doesn't exist in the available context the solver should simply satisfy > it with an empty callstack and that should be the end of it (Eric, > correct me if I'm wrong). > > Indeed, 7.10.2, which also had an early version of implicit callstack > support, did exactly this. I haven't yet looked any further into what > may have changed, but I have opened #11573 to track this. The inferred CallStack is not a bug, it was added to fix #10845. The problem is that in a function like foo :: HasCallStack => ... foo x = let bar y = undefined in bar x we *need* to infer a CallStack for bar (due to the structure of the constraint solver) in order to link foo's CallStack to undefined. Currently, this extends to inferring CallStacks for top-level binders without explicit type signatures. Pedagogic concerns aside, I don't think this is a big deal as it's standard practice to provide explicit signatures. But it wouldn't be hard to make an exception for top-level binders. What *is* a bug is that GHC shows the implicit parameter in the inferred signature. We don't expose those anymore in the CallStack API, instead we use a type synonym HasCallStack. GHC should infer HasCallStack constraints instead. Eric From karel.gardas at centrum.cz Sat Feb 13 18:57:58 2016 From: karel.gardas at centrum.cz (Karel Gardas) Date: Sat, 13 Feb 2016 19:57:58 +0100 Subject: GHC build time graphs In-Reply-To: References: <1454005734-sup-9633@sabre> <010A82CA-A36C-4739-ADFC-1B0035483351@iki.fi> <1454019988.2635.2.camel@joachim-breitner.de> <87k2mtcozq.fsf@smart-cactus.org> <56BA11D4.6050103@centrum.cz> Message-ID: <56BF7CB6.20708@centrum.cz> On 02/12/16 09:02 PM, Reid Barton wrote: > btw, just recent experience on ARM64 (X-gene board): > > bootstrapping 7.10.1 with 7.6.x took: ~120 minutes > bootstrapping 8.0.1 RC2 with 7.10.1 took: ~446 minutes > > both run as: ./configure; time make -j8 > > > It would be interesting to have the time for bootstrapping 7.10.1 with > 7.10.1 too, for comparison. boostrapping 7.10.1 with 7.10.1 took: ~212 minutes -- but this is not comparable directly with numbers above since for whatever reason haddock and doc is not build although I've used previous ./configure; time make -j8. Anyway, parallel make itself is not good to use here since the build process may also contain some noise of paralellel make fixes and such. I think more reliable benchmark may be simple build (single-threaded) of ghc-cabal here. I'll see what I can do about that. Cheers, Karel From karel.gardas at centrum.cz Sat Feb 13 23:10:23 2016 From: karel.gardas at centrum.cz (Karel Gardas) Date: Sun, 14 Feb 2016 00:10:23 +0100 Subject: GHC build time graphs In-Reply-To: <56BF7CB6.20708@centrum.cz> References: <1454005734-sup-9633@sabre> <010A82CA-A36C-4739-ADFC-1B0035483351@iki.fi> <1454019988.2635.2.camel@joachim-breitner.de> <87k2mtcozq.fsf@smart-cactus.org> <56BA11D4.6050103@centrum.cz> <56BF7CB6.20708@centrum.cz> Message-ID: <56BFB7DF.4040802@centrum.cz> On 02/13/16 07:57 PM, Karel Gardas wrote: > On 02/12/16 09:02 PM, Reid Barton wrote: >> btw, just recent experience on ARM64 (X-gene board): >> >> bootstrapping 7.10.1 with 7.6.x took: ~120 minutes >> bootstrapping 8.0.1 RC2 with 7.10.1 took: ~446 minutes >> >> both run as: ./configure; time make -j8 >> >> >> It would be interesting to have the time for bootstrapping 7.10.1 with >> 7.10.1 too, for comparison. > > boostrapping 7.10.1 with 7.10.1 took: ~212 minutes -- but this is not > comparable directly with numbers above since for whatever reason haddock > and doc is not build although I've used previous ./configure; time make > -j8. > > Anyway, parallel make itself is not good to use here since the build > process may also contain some noise of paralellel make fixes and such. > > I think more reliable benchmark may be simple build (single-threaded) of > ghc-cabal here. I'll see what I can do about that. OK, so not everything is that bad. Benchmarking compilation of GHC 7.10.1 ghc-cabal tool reveals: GHC 7.6.3: ~12 minutes GHC 7.10.1: ~24 minutes GHC 8.0.1 RC2: ~14 minutes Please note that GHC 7.6.3 compiles 89 files while GHC 7.10.1 and 8.0.1 RC2 compile 90 files. Test done on the same x-gene board like the tests above for the reference... Karel From jan.stolarek at p.lodz.pl Sun Feb 14 09:28:46 2016 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Sun, 14 Feb 2016 10:28:46 +0100 Subject: Potentially confusing syntax for injective type families In-Reply-To: References: Message-ID: <201602141028.46588.jan.stolarek@p.lodz.pl> > 2. Without the infectivity annotation, this declares an associate type > synonym default. This isn't valid because Ht is not declared as an > associated type before hand and r is not mentioned on the LHS. > > class Hcl a b where > type Ht a b = r Indeed, this is invalid and GHC rejects this, so I think we're OK here. In case of associated types if you want to declare injectivity you need to provide the "| r -> ...." part. Otherwise you're declaring a default. This is documented in the User's Guide for 8.0. 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 matthewtpickering at gmail.com Sun Feb 14 10:56:43 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Sun, 14 Feb 2016 10:56:43 +0000 Subject: Potentially confusing syntax for injective type families In-Reply-To: <201602141028.46588.jan.stolarek@p.lodz.pl> References: <201602141028.46588.jan.stolarek@p.lodz.pl> Message-ID: I guess my point is that the most natural parsing of class Hcl a b where type Ht a b = r | r -> a b is (type Ht a b = r) (| r -> a b) rather than (type Ht a b) (= r | r -> a b). A concrete example, in the case of functional dependencies, the vertical bar is used to signal what we expect *additional* optional information. In this case, adding the injectivity annotation completely changes the meaning of what came before. I don't have a solution and I hate bike-shedding. I just made this message to make sure the fact had been considered before release. Matt On Sun, Feb 14, 2016 at 9:28 AM, Jan Stolarek wrote: >> 2. Without the infectivity annotation, this declares an associate type >> synonym default. This isn't valid because Ht is not declared as an >> associated type before hand and r is not mentioned on the LHS. >> >> class Hcl a b where >> type Ht a b = r > Indeed, this is invalid and GHC rejects this, so I think we're OK here. In case of associated > types if you want to declare injectivity you need to provide the "| r -> ...." part. Otherwise > you're declaring a default. This is documented in the User's Guide for 8.0. > > 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 ben at well-typed.com Sun Feb 14 16:12:50 2016 From: ben at well-typed.com (Ben Gamari) Date: Sun, 14 Feb 2016 17:12:50 +0100 Subject: Reconsidering -Wall and -Wcompat Message-ID: <87y4an6zjx.fsf@smart-cactus.org> tl;dr. GHC has a new set of warnings, -Wcompat, intended to give users advance notice of coming library changes. We want to know whether you think this set should be included in -Wall. See the Wiki [4] and voice your opinion via the linked poll. Hello everyone, GHC 8.0.1 will include a new warning group, -Wcompat, which arose out of the MonadFail proposal discussion [1] late last year. This warning set is intended to provide a means of informing users of coming changes in GHC's core libraries. We would like to solicit the community's feedback on whether this new flag set should be implied by -Wall. This proposal is motivated by concern expressed by some that -Wcompat would see little usage unless it is placed in one of the warning sets typically used during development. One such set is -Wall, which enables a generous fraction of GHC's warning collectionand is is intended [2] for use during development. Unfortunately, despite the (albeit only recently stated) intent of flag, -Wall is widely used outside of development [3], often with the expectation that the result be warning-clean across multiple GHC versions. While we hope that -Wall will see less use in this context in the future, given its current role we wouldn't want to add options to it that would cause undue burden for users. So, we are asking for your opinion: should -Wcompat be implied by -Wall? You can find a more thorough description of the precise proposal on the GHC Wiki [4]. It would be very much appreciated if you could take a few minutes familiarize yourself with the options and provide your thoughts via this quick poll, https://docs.google.com/forms/d/1BmIQvhHcnDB79LgBvaWl_xXpS1q0dMHe3Gq9JeU9odM/viewform Feel free to discuss the issue further in this thread. Thank you for sharing, - Ben [1] https://mail.haskell.org/pipermail/ghc-devs/2015-October/010101.html [2] https://mail.haskell.org/pipermail/ghc-devs/2016-January/010955.html [3] In a rather unscientific study, nearly half of packages on Hackage include it in ghc-options, $ tar -xf ~/.cabal/packages/00-INDEX.tar $ (for pkg in $(ls); do ls $pkg/*/*.cabal | sort -r | head -n1; done) | xargs grep -L '\-Wall' | wc -l 4352 $ ls | wc -l 9347 [4] https://ghc.haskell.org/trac/ghc/wiki/Design/Warnings/Wcompat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From svenpanne at gmail.com Sun Feb 14 18:51:19 2016 From: svenpanne at gmail.com (Sven Panne) Date: Sun, 14 Feb 2016 19:51:19 +0100 Subject: Reconsidering -Wall and -Wcompat In-Reply-To: <87y4an6zjx.fsf@smart-cactus.org> References: <87y4an6zjx.fsf@smart-cactus.org> Message-ID: 2016-02-14 17:12 GMT+01:00 Ben Gamari : > [...] This proposal is motivated by concern expressed by some that -Wcompat > would see little usage unless it is placed in one of the warning sets > typically used during development. One such set is -Wall, which enables > a generous fraction of GHC's warning collectionand is is intended [2] > for use during development. > IMHO, the distinction between "during development" and "outside of it" is purely hypothetical. A typical workflow is: Develop your code locally against one GHC/set of libraries, commit to GitHub and let Travis CI do the real work of testing against a matrix of configurations. If things work well and the changes are worth it, tag your current state and release it. Where exactly in this scenario is the code leaving the "during development" state? I definitely want to enable -Wall for the Travis CI builds, because that's the place where they are most valuable. As stated on the Wiki, stuff in -Wcompat will often be non-actionable, so the only option I see if -Wcompat is included in -Wall will be -Wno-compat for all my projects. -Wcompat would be restricted to a few manual local builds to see where things are heading. > Unfortunately, despite the (albeit only recently stated) intent of > flag, -Wall is widely used outside of development [3], often with the > expectation that the result be warning-clean across multiple GHC > versions. While we hope that -Wall will see less use in this context in > the future, [...] Seeing -Wall this way is quite unusual, especially for people coming from C/C++ (and the numbers quoted from Hackage seem to be a hint that others think so, too). Normally, -Wall -Wextra -pedantic etc. are life-savers and should be kept enabled all the time, unless you like endless debugging hours, of course. In a nutshell: I would consider -Wall implying -Wcompat an annoyance, but as long as it can be disabled by 2 lines in .travis.yml, I don't really care. ;-) Cheers, S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Sun Feb 14 21:59:07 2016 From: ekmett at gmail.com (Edward Kmett) Date: Sun, 14 Feb 2016 16:59:07 -0500 Subject: Potentially confusing syntax for injective type families In-Reply-To: References: <201602141028.46588.jan.stolarek@p.lodz.pl> Message-ID: When this was first discussed a bunch of alternatives were tossed around, mostly involving new keywords, or putting a conditional result keyword in place. Here you can pick the name of the result type, so it doesn't pick any naming conventions for you. My understanding is that the current syntax was selected because it avoids magic conditional keywords and fits into a gap in the current grammar. All of the alternatives seemed worse. -Edward On Sun, Feb 14, 2016 at 5:56 AM, Matthew Pickering < matthewtpickering at gmail.com> wrote: > I guess my point is that the most natural parsing of > > class Hcl a b where > type Ht a b = r | r -> a b > > is (type Ht a b = r) (| r -> a b) rather than (type Ht a b) (= r | r -> a > b). > > A concrete example, in the case of functional dependencies, the > vertical bar is used to signal what we expect *additional* optional > information. In this case, adding the injectivity annotation > completely changes the meaning of what came before. > > I don't have a solution and I hate bike-shedding. I just made this > message to make sure the fact had been considered before release. > > Matt > > > > On Sun, Feb 14, 2016 at 9:28 AM, Jan Stolarek > wrote: > >> 2. Without the infectivity annotation, this declares an associate type > >> synonym default. This isn't valid because Ht is not declared as an > >> associated type before hand and r is not mentioned on the LHS. > >> > >> class Hcl a b where > >> type Ht a b = r > > Indeed, this is invalid and GHC rejects this, so I think we're OK here. > In case of associated > > types if you want to declare injectivity you need to provide the "| r -> > ...." part. Otherwise > > you're declaring a default. This is documented in the User's Guide for > 8.0. > > > > Janek > > > > --- > > Politechnika ??dzka > > Lodz University of Technology > > > > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. > > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez > pomy?k? > > prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. > > > > This email contains information intended solely for the use of the > individual to whom it is addressed. > > If you are not the intended recipient or if you have received this > message in error, > > please notify the sender and delete it from your system. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chak at justtesting.org Sun Feb 14 23:04:45 2016 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Mon, 15 Feb 2016 10:04:45 +1100 Subject: Reconsidering -Wall and -Wcompat In-Reply-To: <87y4an6zjx.fsf@smart-cactus.org> References: <87y4an6zjx.fsf@smart-cactus.org> Message-ID: <58D9ECFB-BBAC-4BA4-8FD5-185F593E1221@justtesting.org> Just as one data point, the Swift compiler is by default showing warnings about upcoming changes. Just like deprecation warnings, I do find that helpful. Based on that experience, including -Wcompat in -Wall seems like a good plan to me. Manuel > Ben Gamari : > > tl;dr. GHC has a new set of warnings, -Wcompat, intended to give users > advance notice of coming library changes. We want to know whether > you think this set should be included in -Wall. See the Wiki [4] > and voice your opinion via the linked poll. > > > Hello everyone, > > GHC 8.0.1 will include a new warning group, -Wcompat, which arose out of > the MonadFail proposal discussion [1] late last year. This warning set > is intended to provide a means of informing users of coming changes in > GHC's core libraries. > > We would like to solicit the community's feedback on whether this new > flag set should be implied by -Wall. > > This proposal is motivated by concern expressed by some that -Wcompat > would see little usage unless it is placed in one of the warning sets > typically used during development. One such set is -Wall, which enables > a generous fraction of GHC's warning collectionand is is intended [2] > for use during development. > > Unfortunately, despite the (albeit only recently stated) intent of > flag, -Wall is widely used outside of development [3], often with the > expectation that the result be warning-clean across multiple GHC > versions. While we hope that -Wall will see less use in this context in > the future, given its current role we wouldn't want to add options to it > that would cause undue burden for users. > > So, we are asking for your opinion: should -Wcompat be implied by -Wall? > You can find a more thorough description of the precise proposal on the > GHC Wiki [4]. It would be very much appreciated if you could take a few > minutes familiarize yourself with the options and provide your thoughts > via this quick poll, > > https://docs.google.com/forms/d/1BmIQvhHcnDB79LgBvaWl_xXpS1q0dMHe3Gq9JeU9odM/viewform > > Feel free to discuss the issue further in this thread. > > Thank you for sharing, > > - Ben > > > > [1] https://mail.haskell.org/pipermail/ghc-devs/2015-October/010101.html > > [2] https://mail.haskell.org/pipermail/ghc-devs/2016-January/010955.html > > [3] In a rather unscientific study, nearly half of packages on Hackage > include it in ghc-options, > > $ tar -xf ~/.cabal/packages/00-INDEX.tar > $ (for pkg in $(ls); do ls $pkg/*/*.cabal | sort -r | head -n1; done) | xargs grep -L '\-Wall' | wc -l > 4352 > $ ls | wc -l > 9347 > > [4] https://ghc.haskell.org/trac/ghc/wiki/Design/Warnings/Wcompat > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From chak at justtesting.org Sun Feb 14 23:14:27 2016 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Mon, 15 Feb 2016 10:14:27 +1100 Subject: Fwd: Is anything being done to remedy the soul crushing compile times of GHC? Message-ID: <4E06663C-C48C-4119-A7A8-8954907B825C@justtesting.org> There is currently an interesting discussion on Reddit on GHC compile times https://www.reddit.com/r/haskell/comments/45q90s/is_anything_being_done_to_remedy_the_soul/ I feel that this is a serious problem; so, it probably ought to be discussed here as well. Manuel From eir at cis.upenn.edu Mon Feb 15 03:47:56 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Sun, 14 Feb 2016 22:47:56 -0500 Subject: Reconsidering -Wall and -Wcompat In-Reply-To: References: <87y4an6zjx.fsf@smart-cactus.org> Message-ID: <7DD5333B-FEE5-40A6-94B8-79D7C1C01757@cis.upenn.edu> On Feb 14, 2016, at 1:51 PM, Sven Panne wrote: > > IMHO, the distinction between "during development" and "outside of it" is purely hypothetical. I find this comment quite interesting, as I see quite a large difference between these.* For example, I use -Werror during development, but not outside it. For me, "during development" is when the author can see the output from the compiler. "Outside of it" is when the author is not looking at the output. When I'm developing, I want to see lots and lots of warnings. When I'm building something I downloaded from Hackage, I generally don't care. So I wonder if there's a way for the tooling to distinguish between development builds and non-dev builds. I know cabal better than stack, so I'll use that as my example. When I say `cabal configure --enable-tests; cabal build`, it means I want more information about how well this package works. Perhaps with --enable-tests, -Wall -Wcompat -Werror should be enabled by default. If I just say `cabal install`, I probably don't care so much about how well the package is working and can leave off the extra diagnostics. The approach of integrating this with tooling like cabal or stack also has the advantage that it is very easy to tailor custom treatment for specific compiler versions. This custom treatment could disable newly-written warnings individually if GHC introduces a new warning that, it is decided, should not be enabled by default on projects that wish to have legacy support. Would this address some of the problems that people have had in this space? Richard * By "interesting" here, I certainly don't mean "stupid". I mean "interesting", because I, like many people, tend to think that others think like I do. This is clearly not the case here, so I have to broaden my viewpoint. From eir at cis.upenn.edu Mon Feb 15 03:58:09 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Sun, 14 Feb 2016 22:58:09 -0500 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: <1455381609.2134.16.camel@gmail.com> References: <87egcg93zn.fsf@smart-cactus.org> <1455381609.2134.16.camel@gmail.com> Message-ID: This approach wouldn't quite work. - It seems to kick in only when instantiating a Levity variable. That would not happen when using :info. - It is possible to have unlifted types about even without -XMagicHash. -XMagicHash is simply a lexer extension, nothing more. By convention, we use the # suffix with unlifted things, but there's no requirement here. Having -XMagicHash thus imply a flag about the type system is bizarre. Furthermore, I'm not sure what the practical, user-visible improvement would be over the approach you include and the -fshow-runtime-rep idea. Richard On Feb 13, 2016, at 11:40 AM, Yuras Shumovich wrote: > > Thank you for the summary! The thread is too big to find anything in > it. > > I'd like to present a bit different approach, kind of a compromise, > without lie and code breakage: introduce a language pragma for levity > polymorphism and default levity polymorphic signatures to "*" when the > pragma is not enabled. > > For example, ($) could be defined like it is right now: > > ($) > :: forall (w :: GHC.Types.Levity) a (b :: TYPE w). > (a -> b) -> a -> b > > But when it is used in a module without levity polymorphism enabled, > "w" is defaulted to "Lifted", "b" gets kind "*", and ($) gets its old > type: > > ($) > :: (a -> b) -> a -> b > > So any use of ($) with types on kind "#" is disallowed. > > But with levily polymorphism enabled, one will see the full type and > use ($) with unlifted types. To prevent breakage of the existing code, > MagicHash extension should by default imply levity polymorphism. > > What do you think? Am I missing something? > > Thanks, > Yuras. > >> * There are further questions regarding the appropriate kinds >> of (->) and (.) [1] >> >> * Incidentally, there is a GHC or Haddock bug [2] which causes kind >> signatures to be unnecessarily shown in documentation for some >> types, >> exposing levities to the user. >> >> The current plan to address this situation is as follows, >> >> * Introduce [3] a flag, -fshow-runtime-rep, which when disabled will >> cause the pretty-printer to instantiate levity-polymorphic types >> as >> lifted (e.g. resulting in *). This flag will be off by default, >> meaning that users will in most cases see the usual lifted types >> unless they explicitly request otherwise. >> >> * Fix the GHC/Haddock bug, restoring elision of unnecessary kind >> signatures in documentation. >> >> * In the future we should seriously consider introducing an >> alternate >> Prelude for beginners >> >> As far as I can tell from the discussion, this was an acceptable >> solution to all involved. If there are any remaining objections or >> concerns let's discuss them in another thread. >> >> Thanks to everyone who contributed to this effort. >> >> Cheers, >> >> - Ben >> >> >> [1] https://ghc.haskell.org/trac/ghc/ticket/10343#comment:27 >> [2] https://ghc.haskell.org/trac/ghc/ticket/11567 >> [3] https://ghc.haskell.org/trac/ghc/ticket/11549 >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From jan.stolarek at p.lodz.pl Mon Feb 15 07:28:56 2016 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Mon, 15 Feb 2016 08:28:56 +0100 Subject: Potentially confusing syntax for injective type families In-Reply-To: References: <201602141028.46588.jan.stolarek@p.lodz.pl> Message-ID: <201602150828.56932.jan.stolarek@p.lodz.pl> > I don't have a solution and I hate bike-shedding. I just made this > message to make sure the fact had been considered before release. Yes, I bumped into this issue quite early. After some discussion it was decided that this potential ambiguity is an acceptable trade-off. Janek Dnia niedziela, 14 lutego 2016, Matthew Pickering napisa?: > I guess my point is that the most natural parsing of > > class Hcl a b where > type Ht a b = r | r -> a b > > is (type Ht a b = r) (| r -> a b) rather than (type Ht a b) (= r | r -> a > b). > > A concrete example, in the case of functional dependencies, the > vertical bar is used to signal what we expect *additional* optional > information. In this case, adding the injectivity annotation > completely changes the meaning of what came before. > > I don't have a solution and I hate bike-shedding. I just made this > message to make sure the fact had been considered before release. > > Matt > > On Sun, Feb 14, 2016 at 9:28 AM, Jan Stolarek wrote: > >> 2. Without the infectivity annotation, this declares an associate type > >> synonym default. This isn't valid because Ht is not declared as an > >> associated type before hand and r is not mentioned on the LHS. > >> > >> class Hcl a b where > >> type Ht a b = r > > > > Indeed, this is invalid and GHC rejects this, so I think we're OK here. > > In case of associated types if you want to declare injectivity you need > > to provide the "| r -> ...." part. Otherwise you're declaring a default. > > This is documented in the User's Guide for 8.0. > > > > 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. --- 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 tab at snarc.org Mon Feb 15 09:44:45 2016 From: tab at snarc.org (Vincent Hanquez) Date: Mon, 15 Feb 2016 09:44:45 +0000 Subject: Impredicative types and forall regression in 8.0 ? Message-ID: <56C19E0D.6090506@snarc.org> Hi GHC-Devs, I recently came across a compilation problem on 8.0 that do not trigger on < 8.0. I've reduced the issue to this snippet with Rank2Types: type Action = (forall a . Show a => a) -> Int data Command = Command (Maybe Action) com1 = Command Nothing With GHC 7.0 to 7.10, this compile and works. However on GHC 8.0, I now have: Test.hs:19:16: error: ? Cannot instantiate unification variable ?a0? with a type involving foralls: Action GHC doesn't yet support impredicative polymorphism ? In the first argument of ?Command?, namely ?Nothing? In the expression: Command Nothing In an equation for ?com1?: com1 = Command Nothing I workarounded it by "inlining" the maybe and creating a proper wrapping type: data Action2 = Action2 ((forall a . Show a => a) -> Int) | NoAction2 data Command2 = Command2 Action2 com2 = Command2 NoAction2 Any idea why this is triggering this issue in GHC 8.0 ? Is this something that need fixing maybe ? Cheers, -- Vincent From hvriedel at gmail.com Mon Feb 15 09:50:55 2016 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Mon, 15 Feb 2016 10:50:55 +0100 Subject: Reconsidering -Wall and -Wcompat In-Reply-To: <7DD5333B-FEE5-40A6-94B8-79D7C1C01757@cis.upenn.edu> (Richard Eisenberg's message of "Sun, 14 Feb 2016 22:47:56 -0500") References: <87y4an6zjx.fsf@smart-cactus.org> <7DD5333B-FEE5-40A6-94B8-79D7C1C01757@cis.upenn.edu> Message-ID: <8737su5mkg.fsf@gmail.com> On 2016-02-15 at 04:47:56 +0100, Richard Eisenberg wrote: > On Feb 14, 2016, at 1:51 PM, Sven Panne wrote: >> >> IMHO, the distinction between "during development" and "outside of it" is purely hypothetical. > > I find this comment quite interesting, as I see quite a large > difference between these.* For example, I use -Werror during > development, but not outside it. For me, "during development" is when > the author can see the output from the compiler. "Outside of it" is > when the author is not looking at the output. > > When I'm developing, I want to see lots and lots of warnings. > > When I'm building something I downloaded from Hackage, I generally don't care. > > So I wonder if there's a way for the tooling to distinguish between > development builds and non-dev builds. You may be interested in the upcoming `cabal.project`-file feature which besides allowing to specify which .cabal files your multi-package project is made up of (and tells cabal where your project-root is), allows to set additional `ghc-options`, specify whether tests/benchmarks are to be enabled, or request specific cabal flag settings (basically most things you can set via the CLI as well), or even which GHC compiler executable to use (rather than picking up whatever's in PATH). This can be specified for all packages in the project or on per-package granularity. `cabal.project` files have only an effect when you're triggering cabal invocations from within a source-tree, i.e. when you're in the "during development" mode. So that would be a good place to specify your development-mode GHC warning-flag configuration and other development-centric configurations. > I know cabal better than stack, so I'll use that as my example. When I > say `cabal configure --enable-tests; cabal build`, it means I want > more information about how well this package works. Perhaps with > --enable-tests, -Wall -Wcompat -Werror should be enabled by > default. If I just say `cabal install`, I probably don't care so much > about how well the package is working and can leave off the extra > diagnostics. From m at tweag.io Mon Feb 15 10:00:03 2016 From: m at tweag.io (Boespflug, Mathieu) Date: Mon, 15 Feb 2016 11:00:03 +0100 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: References: <87egcg93zn.fsf@smart-cactus.org> <1455381609.2134.16.camel@gmail.com> Message-ID: Hi Ben, thanks for the nice summary. I haven't been following all the details in the meanderings of this thread, but perhaps someone can chime in with an answer to this simple question: * has it been discussed what type ($) should have in the Haddock's for base? If so, will it the one GHCi shows by default, or the one GHCi will show when -fshow-runtime-rep? If the former, how is a user supposed to discover that ($) is in fact more general than what the docs would tell you? If the latter, wouldn't the Haddock's be just as confusing to beginners as GHCi's output currently is? Wouldn't it be even more confusing that the Haddock's and GHCi don't agree about what the type of ($) really is? Many thanks, -- Mathieu Boespflug Founder at http://tweag.io. On 15 February 2016 at 04:58, Richard Eisenberg wrote: > This approach wouldn't quite work. > > - It seems to kick in only when instantiating a Levity variable. That would not happen when using :info. > > - It is possible to have unlifted types about even without -XMagicHash. -XMagicHash is simply a lexer extension, nothing more. By convention, we use the # suffix with unlifted things, but there's no requirement here. Having -XMagicHash thus imply a flag about the type system is bizarre. > > Furthermore, I'm not sure what the practical, user-visible improvement would be over the approach you include and the -fshow-runtime-rep idea. > > Richard > > > > On Feb 13, 2016, at 11:40 AM, Yuras Shumovich wrote: >> >> Thank you for the summary! The thread is too big to find anything in >> it. >> >> I'd like to present a bit different approach, kind of a compromise, >> without lie and code breakage: introduce a language pragma for levity >> polymorphism and default levity polymorphic signatures to "*" when the >> pragma is not enabled. >> >> For example, ($) could be defined like it is right now: >> >> ($) >> :: forall (w :: GHC.Types.Levity) a (b :: TYPE w). >> (a -> b) -> a -> b >> >> But when it is used in a module without levity polymorphism enabled, >> "w" is defaulted to "Lifted", "b" gets kind "*", and ($) gets its old >> type: >> >> ($) >> :: (a -> b) -> a -> b >> >> So any use of ($) with types on kind "#" is disallowed. >> >> But with levily polymorphism enabled, one will see the full type and >> use ($) with unlifted types. To prevent breakage of the existing code, >> MagicHash extension should by default imply levity polymorphism. >> >> What do you think? Am I missing something? >> >> Thanks, >> Yuras. >> >>> * There are further questions regarding the appropriate kinds >>> of (->) and (.) [1] >>> >>> * Incidentally, there is a GHC or Haddock bug [2] which causes kind >>> signatures to be unnecessarily shown in documentation for some >>> types, >>> exposing levities to the user. >>> >>> The current plan to address this situation is as follows, >>> >>> * Introduce [3] a flag, -fshow-runtime-rep, which when disabled will >>> cause the pretty-printer to instantiate levity-polymorphic types >>> as >>> lifted (e.g. resulting in *). This flag will be off by default, >>> meaning that users will in most cases see the usual lifted types >>> unless they explicitly request otherwise. >>> >>> * Fix the GHC/Haddock bug, restoring elision of unnecessary kind >>> signatures in documentation. >>> >>> * In the future we should seriously consider introducing an >>> alternate >>> Prelude for beginners >>> >>> As far as I can tell from the discussion, this was an acceptable >>> solution to all involved. If there are any remaining objections or >>> concerns let's discuss them in another thread. >>> >>> Thanks to everyone who contributed to this effort. >>> >>> Cheers, >>> >>> - Ben >>> >>> >>> [1] https://ghc.haskell.org/trac/ghc/ticket/10343#comment:27 >>> [2] https://ghc.haskell.org/trac/ghc/ticket/11567 >>> [3] https://ghc.haskell.org/trac/ghc/ticket/11549 >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From marlowsd at gmail.com Mon Feb 15 10:12:31 2016 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 15 Feb 2016 10:12:31 +0000 Subject: New type of expressions containing (error ...) includes noisy implicit parameter In-Reply-To: References: Message-ID: On 13 February 2016 at 08:32, Christopher Allen wrote: > Prelude> let myList = [1, 2, 3 :: Integer] > Prelude> let myList' = myList ++ undefined > Prelude> :t myList > myList :: [Integer] > Prelude> :t myList' > myList' :: (?callStack::GHC.Stack.Types.CallStack) => [Integer] > Yes, and I think perhaps an even more worrying problem here is that by adding the reference to undefined, myList went from being a thunk to being a function. That is, it will be re-evaluated each time it it used. I made a ticket about this: https://ghc.haskell.org/trac/ghc/ticket/11383 Cheers Simon > This is on by default and insofar as I've been able to try, it's avoidable > in a default GHCi 8.0 REPL session. I'm glad I caught this before our book > goes to print in a couple months. We'd managed to avoid talking about > implicit parameters in 1,100+ pages of book but now we're forced to > acknowledge their existence in the 4th of 32 chapters. > > This slipped past the radar more stealthily than the earlier stages of BBP > did for 7.10. I was hearing about BBP on the GHC Trac pretty early on for > months on end. Was the thinking that people still used implicit parameters > for anything or taught them? On the one hand, this is a nice change and > something I personally attempted (and failed) to make easier in GHC 7.10. > The implementation making the types noisy rankles and didn't seem necessary > when I investigated it between 7.8 and 7.10. > > Could you warn us when (educationally relevant?) stuff like this is coming > down the pipe before the RC please? Ideally during the design phase. I > think this was discussed as part of FTP to avoid future debacles. > > This isn't just a pedagogical problem, this is a UX problem. The users > don't _care_ that call stack information is being carried around. Why would > they? It happens without any mention in the types in almost every other > programming language. > > > --- Chris Allen > > > _______________________________________________ > 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 m at tweag.io Mon Feb 15 10:33:09 2016 From: m at tweag.io (Boespflug, Mathieu) Date: Mon, 15 Feb 2016 11:33:09 +0100 Subject: Reconsidering -Wall and -Wcompat In-Reply-To: <87y4an6zjx.fsf@smart-cactus.org> References: <87y4an6zjx.fsf@smart-cactus.org> Message-ID: Hi Ben, could we enlarge the options a bit? I feel that we're in a false dichotomy currently. I think the issue isn't so much what warnings you see from the compiler with common settings, so much as "what warnings will cause my build to fail?". i.e. the issue isn't what's in -Wall, it's what goes in -Werror... If we don't include -Wcompat in -Wall, then I suspect Ben is quite right that many will ignore / not be aware of -Wcompat hence rendering the 3 release policy rather moot (it's much less useful if developers don't /know/ they're incompatible until the last minute). If we do include it then packages with -Wall -Werror will fail far too early: i.e. way before the compat change actually happens, 3 compiler releases down the line. So may I suggest the following: * include -Wcompat and -Wall, but make it "magic" so that -Wcompat never causes a build to fail even when users set -Wall -Werror. This should address the concerns I've been hearing by folks at large companies who say that at their company a warning is equivalent to an error, because they always compile with -Wall -Werror. Otherwise warnings just accumulate, hence no one pays attention to them, hence warnings become useless. As an aside: I believe -Wall should do what it says on the tin: enable all warnings. When GHC comes up with new warnings, we should pretty much never hesitate to add them to the -Wall set. At Tweag I/O we've had one instance of a serious bug that shipped into production and several days worth of wasted effort, because a constraint maintaining a key invariant was mistakenly unused. -fwarn-redundant-constraints would of caught this bug very early and saved us all the trouble (a test would have worked too, but as it happens a test did exist but had a bug too). Best, -- Mathieu Boespflug Founder at http://tweag.io. On 14 February 2016 at 17:12, Ben Gamari wrote: > tl;dr. GHC has a new set of warnings, -Wcompat, intended to give users > advance notice of coming library changes. We want to know whether > you think this set should be included in -Wall. See the Wiki [4] > and voice your opinion via the linked poll. > > > Hello everyone, > > GHC 8.0.1 will include a new warning group, -Wcompat, which arose out of > the MonadFail proposal discussion [1] late last year. This warning set > is intended to provide a means of informing users of coming changes in > GHC's core libraries. > > We would like to solicit the community's feedback on whether this new > flag set should be implied by -Wall. > > This proposal is motivated by concern expressed by some that -Wcompat > would see little usage unless it is placed in one of the warning sets > typically used during development. One such set is -Wall, which enables > a generous fraction of GHC's warning collectionand is is intended [2] > for use during development. > > Unfortunately, despite the (albeit only recently stated) intent of > flag, -Wall is widely used outside of development [3], often with the > expectation that the result be warning-clean across multiple GHC > versions. While we hope that -Wall will see less use in this context in > the future, given its current role we wouldn't want to add options to it > that would cause undue burden for users. > > So, we are asking for your opinion: should -Wcompat be implied by -Wall? > You can find a more thorough description of the precise proposal on the > GHC Wiki [4]. It would be very much appreciated if you could take a few > minutes familiarize yourself with the options and provide your thoughts > via this quick poll, > > https://docs.google.com/forms/d/1BmIQvhHcnDB79LgBvaWl_xXpS1q0dMHe3Gq9JeU9odM/viewform > > Feel free to discuss the issue further in this thread. > > Thank you for sharing, > > - Ben > > > > [1] https://mail.haskell.org/pipermail/ghc-devs/2015-October/010101.html > > [2] https://mail.haskell.org/pipermail/ghc-devs/2016-January/010955.html > > [3] In a rather unscientific study, nearly half of packages on Hackage > include it in ghc-options, > > $ tar -xf ~/.cabal/packages/00-INDEX.tar > $ (for pkg in $(ls); do ls $pkg/*/*.cabal | sort -r | head -n1; done) | xargs grep -L '\-Wall' | wc -l > 4352 > $ ls | wc -l > 9347 > > [4] https://ghc.haskell.org/trac/ghc/wiki/Design/Warnings/Wcompat > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From hvriedel at gmail.com Mon Feb 15 10:43:02 2016 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Mon, 15 Feb 2016 11:43:02 +0100 Subject: Reconsidering -Wall and -Wcompat In-Reply-To: (Sven Panne's message of "Sun, 14 Feb 2016 19:51:19 +0100") References: <87y4an6zjx.fsf@smart-cactus.org> Message-ID: <87twla45l5.fsf@gmail.com> On 2016-02-14 at 19:51:19 +0100, Sven Panne wrote: [...] > As stated on the Wiki, stuff in -Wcompat will often be non-actionable, > so the only option I see if -Wcompat is included in -Wall will be > -Wno-compat for all my projects. This depends on what we mean by "actionable". I'm not sure I'd consider the current -Wcompat warnings to be "non-actionable". For instance, `aeson-0.11` happens to be free of -Wall -Wcompat -Wnoncanonical-monad-instances -Wnoncanonical-monadfail-instances warnings, which didn't require any CPP, see e.g. - https://github.com/bos/aeson/pull/337/files - https://github.com/bos/aeson/pull/338/files Also, as an example for a larger code-base, {Cabal,cabal-install} HEAD in Git aspire to be warning-free as well[1]; so depending on your definition, -Wcompat *is* actionable. > -Wcompat would be restricted to a few manual local builds to see where > things are heading. [1]: See .e.g. https://github.com/haskell/cabal/blob/master/Cabal/Cabal.cabal#L191-L193 if impl(ghc >= 8.0) ghc-options: -Wcompat -Wnoncanonical-monad-instances -Wnoncanonical-monadfail-instances and the Travis job enables -Werror From hvriedel at gmail.com Mon Feb 15 10:48:22 2016 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Mon, 15 Feb 2016 11:48:22 +0100 Subject: Reconsidering -Wall and -Wcompat In-Reply-To: (Mathieu Boespflug's message of "Mon, 15 Feb 2016 11:33:09 +0100") References: <87y4an6zjx.fsf@smart-cactus.org> Message-ID: <87povy45c9.fsf@gmail.com> On 2016-02-15 at 11:33:09 +0100, Boespflug, Mathieu wrote: [...] > * include -Wcompat and -Wall, but make it "magic" so that -Wcompat > never causes a build to fail even when users set -Wall -Werror. Tbh, I don't like the "magic" part at all. In fact, I currently rely on `-Wcompat -Werror` triggering an error in my builds. To address the concern more generally is what https://ghc.haskell.org/trac/ghc/ticket/11219 aims to, but without any magic. Then you'd say -Wall -Werror -Wno-error=compat if -Wcompat implied by -Wall. But we ran out of time for GHC 8.0, so #11219 will have to wait till GHC 8.2. From adam at well-typed.com Mon Feb 15 10:49:43 2016 From: adam at well-typed.com (Adam Gundry) Date: Mon, 15 Feb 2016 10:49:43 +0000 Subject: Impredicative types and forall regression in 8.0 ? In-Reply-To: <56C19E0D.6090506@snarc.org> References: <56C19E0D.6090506@snarc.org> Message-ID: <56C1AD47.3020305@well-typed.com> Hi Vincent, On 15/02/16 09:44, Vincent Hanquez wrote: > I recently came across a compilation problem on 8.0 that do not trigger > on < 8.0. I've reduced the issue to this snippet with Rank2Types: > > type Action = (forall a . Show a => a) -> Int > data Command = Command (Maybe Action) > > com1 = Command Nothing > > With GHC 7.0 to 7.10, this compile and works. This shouldn't be accepted without ImpredicativeTypes[*], but GHC versions prior to 8.0 failed to look through the type synonym. Note that if you say data Command = Command (Maybe ((forall a . Show a => a) -> Int)) then earlier versions report an error. Take a look at GHC ticket #10194 for more details: https://ghc.haskell.org/trac/ghc/ticket/10194 > However on GHC 8.0, I now have: > > Test.hs:19:16: error: > ? Cannot instantiate unification variable ?a0? > with a type involving foralls: Action > GHC doesn't yet support impredicative polymorphism > ? In the first argument of ?Command?, namely ?Nothing? > In the expression: Command Nothing > In an equation for ?com1?: com1 = Command Nothing > > I workarounded it by "inlining" the maybe and creating a proper wrapping > type: > > data Action2 = Action2 ((forall a . Show a => a) -> Int) | NoAction2 > data Command2 = Command2 Action2 > > com2 = Command2 NoAction2 This looks like a reasonable alternative. Hope this helps, Adam [*] And if you turn on ImpredicativeTypes, GHC may or may not do the right thing. -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From ben at smart-cactus.org Mon Feb 15 10:52:58 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 15 Feb 2016 11:52:58 +0100 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: References: <87egcg93zn.fsf@smart-cactus.org> <1455381609.2134.16.camel@gmail.com> Message-ID: <87si0u6y9h.fsf@smart-cactus.org> "Boespflug, Mathieu" writes: > Hi Ben, > > thanks for the nice summary. I haven't been following all the details > in the meanderings of this thread, but perhaps someone can chime in > with an answer to this simple question: > > * has it been discussed what type ($) should have in the Haddock's for > base? If so, will it the one GHCi shows by default, or the one GHCi > will show when -fshow-runtime-rep? > > If the former, how is a user supposed to discover that ($) is in fact > more general than what the docs would tell you? > > If the latter, wouldn't the Haddock's be just as confusing to > beginners as GHCi's output currently is? Wouldn't it be even more > confusing that the Haddock's and GHCi don't agree about what the type > of ($) really is? > Indeed, the disagreement is confusing, but we have been living with this confusion for quite some time now as ($) is already open-kinded. If nothing else, this new state of affairs is slightly better since if you know the secret -fshow-runtime-rep incantation you can convince GHCi to tell you the real type. As far as I know, there is currently know way to do this in 7.10. Given how much backlash there has been to changing the type of ($), I'd be fine not using -fshow-runtime-rep during the core library haddock builds. In effect the message to users would be, "yes, unboxed types exist and they are now on sound theoretical footing, but they are still largely an implementation detail, just as they have always been. If you want to use them you need to know where to look." Perhaps this can be revisited at some point in the future when we have a better story for a beginner's Prelude but for now I'm not sure we want to subject everyone to these new types. Anyways, this is just my two cents. It would be nice to hear what others think. 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 shumovichy at gmail.com Mon Feb 15 11:00:23 2016 From: shumovichy at gmail.com (Yuras Shumovich) Date: Mon, 15 Feb 2016 14:00:23 +0300 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: References: <87egcg93zn.fsf@smart-cactus.org> <1455381609.2134.16.camel@gmail.com> Message-ID: <1455534023.2134.35.camel@gmail.com> Thank you for the reply! On Sun, 2016-02-14 at 22:58 -0500, Richard Eisenberg wrote: > This approach wouldn't quite work. > > - It seems to kick in only when instantiating a Levity variable. That > would not happen when using :info. Obviously Levity variables should be defaulted to Lifted everywhere, including :info and :type. Is it possible or are there some technical limitations? > > - It is possible to have unlifted types about even without > -XMagicHash. -XMagicHash is simply a lexer extension, nothing more. > By convention, we use the # suffix with unlifted things, but there's > no requirement here. Having -XMagicHash thus imply a flag about the > type system is bizarre. OK, I always forget about that. But is not it a bug already? Usually we don't allow code that uses GHC-specific extensions to compile without a language pragma. Why we don't have such pragma for levity polymorphism? If we agree that we need a pragma, then we can find a way to introduce it without massive code breakage, e.g. we can add a warning to -Wcompat and make the pragma mandatory in 3 releases. Then we can have -fshow- runtime-rep as a temporary solution. It naturally solves an issue with Haddock -- it should show levity polymorphic type when an identifier is exported from a module with the pragma, and monomorphic type otherwise. Basically that is what haddock does for KindSignatures. > > Furthermore, I'm not sure what the practical, user-visible > improvement would be over the approach you include and the -fshow- > runtime-rep idea. The improvement is to keep ($) type as specified by Haskell2010 report (including :info) and never lie about it, but allow levity polymorphism when explicitly requested by user. > > Richard > > > > On Feb 13, 2016, at 11:40 AM, Yuras Shumovich > wrote: > > > > Thank you for the summary! The thread is too big to find anything > > in > > it. > > > > I'd like to present a bit different approach, kind of a compromise, > > without lie and code breakage: introduce a language pragma for > > levity > > polymorphism and default levity polymorphic signatures to "*" when > > the > > pragma is not enabled. > > > > For example, ($) could be defined like it is right now: > > > > ($) > > ? :: forall (w :: GHC.Types.Levity) a (b :: TYPE w). > > ?????(a -> b) -> a -> b > > > > But when it is used in a module without levity polymorphism > > enabled, > > "w" is defaulted to "Lifted", "b" gets kind "*", and ($) gets its > > old > > type: > > > > ($) > > ? :: (a -> b) -> a -> b > > > > So any use of ($) with types on kind "#" is disallowed. > > > > But with levily polymorphism enabled, one will see the full type > > and > > use ($) with unlifted types. To prevent breakage of the existing > > code, > > MagicHash extension should by default imply levity polymorphism. > > > > What do you think? Am I missing something? > > > > Thanks, > > Yuras. > > > > > ?* There are further questions regarding the appropriate kinds > > > ???of (->) and (.) [1] > > > > > > ?* Incidentally, there is a GHC or Haddock bug [2] which causes > > > kind > > > ???signatures to be unnecessarily shown in documentation for some > > > types, > > > ???exposing levities to the user. > > > > > > The current plan to address this situation is as follows, > > > > > > ?* Introduce [3] a flag, -fshow-runtime-rep, which when disabled > > > will > > > ???cause the pretty-printer to instantiate levity-polymorphic > > > types > > > as > > > ???lifted (e.g. resulting in *). This flag will be off by > > > default, > > > ???meaning that users will in most cases see the usual lifted > > > types > > > ???unless they explicitly request otherwise. > > > > > > ?* Fix the GHC/Haddock bug, restoring elision of unnecessary kind > > > ???signatures in documentation. > > > > > > ?* In the future we should seriously consider introducing an > > > alternate > > > ???Prelude for beginners > > > ? > > > As far as I can tell from the discussion, this was an acceptable > > > solution to all involved. If there are any remaining objections > > > or > > > concerns let's discuss them in another thread. > > > > > > Thanks to everyone who contributed to this effort. > > > > > > Cheers, > > > > > > - Ben > > > > > > > > > [1] https://ghc.haskell.org/trac/ghc/ticket/10343#comment:27 > > > [2] https://ghc.haskell.org/trac/ghc/ticket/11567 > > > [3] https://ghc.haskell.org/trac/ghc/ticket/11549 > > > _______________________________________________ > > > 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 m at tweag.io Mon Feb 15 11:04:43 2016 From: m at tweag.io (Boespflug, Mathieu) Date: Mon, 15 Feb 2016 12:04:43 +0100 Subject: Reconsidering -Wall and -Wcompat In-Reply-To: <87povy45c9.fsf@gmail.com> References: <87y4an6zjx.fsf@smart-cactus.org> <87povy45c9.fsf@gmail.com> Message-ID: >> * include -Wcompat and -Wall, but make it "magic" so that -Wcompat >> never causes a build to fail even when users set -Wall -Werror. > > Tbh, I don't like the "magic" part at all. In fact, I currently rely on > `-Wcompat -Werror` triggering an error in my builds. Point is - if -Wall implies -Wcompat that's simply not an option for many companies, who have a huge codebase, turn on -Wall -Werror as a matter of policy yet need the time granted by the 3 release policy to adapt their codebase. > To address the concern more generally is what > > https://ghc.haskell.org/trac/ghc/ticket/11219 > > aims to, but without any magic. Then you'd say > > -Wall -Werror -Wno-error=compat > > if -Wcompat implied by -Wall. That sounds good. -Wno-error=compat should work fine. > But we ran out of time for GHC 8.0, so #11219 will have to wait till GHC 8.2. Then is it reasonable to prevent -Wall -Werror from failing builds because of -Wcompat through some kind of special casing in GHC 8.0, to be generalized via -Wno-error in GHC 8.2? From shumovichy at gmail.com Mon Feb 15 11:20:18 2016 From: shumovichy at gmail.com (Yuras Shumovich) Date: Mon, 15 Feb 2016 14:20:18 +0300 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: <1455534023.2134.35.camel@gmail.com> References: <87egcg93zn.fsf@smart-cactus.org> <1455381609.2134.16.camel@gmail.com> <1455534023.2134.35.camel@gmail.com> Message-ID: <1455535218.2134.37.camel@gmail.com> On Mon, 2016-02-15 at 14:00 +0300, Yuras Shumovich wrote: > Thank you for the reply! > > On Sun, 2016-02-14 at 22:58 -0500, Richard Eisenberg wrote: > > This approach wouldn't quite work. > > > > - It seems to kick in only when instantiating a Levity variable. > > That > > would not happen when using :info. > > Obviously Levity variables should be defaulted to Lifted everywhere, > including :info and :type. Is it possible or are there some technical > limitations? > > > > > - It is possible to have unlifted types about even without > > -XMagicHash. -XMagicHash is simply a lexer extension, nothing more. > > By convention, we use the # suffix with unlifted things, but > > there's > > no requirement here. Having -XMagicHash thus imply a flag about the > > type system is bizarre. > > OK, I always forget about that. But is not it a bug already? Usually > we > don't allow code that uses GHC-specific extensions to compile without > a > language pragma. Why we don't have such pragma for levity > polymorphism? > If we agree that we need a pragma, then we can find a way to > introduce > it without massive code breakage, e.g. we can add a warning to > -Wcompat > and make the pragma mandatory in 3 releases. Then we can have -fshow- > runtime-rep as a temporary solution. Correction: we don't need -fshow-runtime-rep even temporary, -XLevilyPolymorphism flag in ghci will be sufficient. > > It naturally solves an issue with Haddock -- it should show levity > polymorphic type when an identifier is exported from a module with > the > pragma, and monomorphic type otherwise. Basically that is what > haddock > does for KindSignatures. > > > > > Furthermore, I'm not sure what the practical, user-visible > > improvement would be over the approach you include and the -fshow- > > runtime-rep idea. > > The improvement is to keep ($) type as specified by Haskell2010 > report > (including :info) and never lie about it, but allow levity > polymorphism > when explicitly requested by user. > > > > > Richard > > > > > > > > On Feb 13, 2016, at 11:40 AM, Yuras Shumovich > > > > wrote: > > > > > > Thank you for the summary! The thread is too big to find anything > > > in > > > it. > > > > > > I'd like to present a bit different approach, kind of a > > > compromise, > > > without lie and code breakage: introduce a language pragma for > > > levity > > > polymorphism and default levity polymorphic signatures to "*" > > > when > > > the > > > pragma is not enabled. > > > > > > For example, ($) could be defined like it is right now: > > > > > > ($) > > > ? :: forall (w :: GHC.Types.Levity) a (b :: TYPE w). > > > ?????(a -> b) -> a -> b > > > > > > But when it is used in a module without levity polymorphism > > > enabled, > > > "w" is defaulted to "Lifted", "b" gets kind "*", and ($) gets its > > > old > > > type: > > > > > > ($) > > > ? :: (a -> b) -> a -> b > > > > > > So any use of ($) with types on kind "#" is disallowed. > > > > > > But with levily polymorphism enabled, one will see the full type > > > and > > > use ($) with unlifted types. To prevent breakage of the existing > > > code, > > > MagicHash extension should by default imply levity polymorphism. > > > > > > What do you think? Am I missing something? > > > > > > Thanks, > > > Yuras. > > > > > > > ?* There are further questions regarding the appropriate kinds > > > > ???of (->) and (.) [1] > > > > > > > > ?* Incidentally, there is a GHC or Haddock bug [2] which causes > > > > kind > > > > ???signatures to be unnecessarily shown in documentation for > > > > some > > > > types, > > > > ???exposing levities to the user. > > > > > > > > The current plan to address this situation is as follows, > > > > > > > > ?* Introduce [3] a flag, -fshow-runtime-rep, which when > > > > disabled > > > > will > > > > ???cause the pretty-printer to instantiate levity-polymorphic > > > > types > > > > as > > > > ???lifted (e.g. resulting in *). This flag will be off by > > > > default, > > > > ???meaning that users will in most cases see the usual lifted > > > > types > > > > ???unless they explicitly request otherwise. > > > > > > > > ?* Fix the GHC/Haddock bug, restoring elision of unnecessary > > > > kind > > > > ???signatures in documentation. > > > > > > > > ?* In the future we should seriously consider introducing an > > > > alternate > > > > ???Prelude for beginners > > > > ? > > > > As far as I can tell from the discussion, this was an > > > > acceptable > > > > solution to all involved. If there are any remaining objections > > > > or > > > > concerns let's discuss them in another thread. > > > > > > > > Thanks to everyone who contributed to this effort. > > > > > > > > Cheers, > > > > > > > > - Ben > > > > > > > > > > > > [1] https://ghc.haskell.org/trac/ghc/ticket/10343#comment:27 > > > > [2] https://ghc.haskell.org/trac/ghc/ticket/11567 > > > > [3] https://ghc.haskell.org/trac/ghc/ticket/11549 > > > > _______________________________________________ > > > > 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 hvriedel at gmail.com Mon Feb 15 11:35:42 2016 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Mon, 15 Feb 2016 12:35:42 +0100 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: <1455534023.2134.35.camel@gmail.com> (Yuras Shumovich's message of "Mon, 15 Feb 2016 14:00:23 +0300") References: <87egcg93zn.fsf@smart-cactus.org> <1455381609.2134.16.camel@gmail.com> <1455534023.2134.35.camel@gmail.com> Message-ID: <87io1q435d.fsf@gmail.com> On 2016-02-15 at 12:00:23 +0100, Yuras Shumovich wrote: [...] >> - It is possible to have unlifted types about even without >> -XMagicHash. -XMagicHash is simply a lexer extension, nothing more. >> By convention, we use the # suffix with unlifted things, but there's >> no requirement here. Having -XMagicHash thus imply a flag about the >> type system is bizarre. > > OK, I always forget about that. But is not it a bug already? Usually we > don't allow code that uses GHC-specific extensions to compile without a > language pragma. Why we don't have such pragma for levity > polymorphism? There are extensions which are only needed at the definition site. Take {-# LANGUAGE PolyKinds #-} for instance; this is enabled inside the Data.Proxy module, which defines the following type {-# LANGUAGE PolyKinds #-} module Data.Proxy where data Proxy t = Proxy Now when you query via GHCi 7.10, you get the following output > import Data.Proxy > :i Proxy type role Proxy phantom data Proxy (t :: k) = Proxy -- Defined in ?Data.Proxy? instance forall (k :: BOX) (s :: k). Bounded (Proxy s) -- Defined in ?Data.Proxy? instance forall (k :: BOX) (s :: k). Enum (Proxy s) -- Defined in ?Data.Proxy? instance forall (k :: BOX) (s :: k). Eq (Proxy s) -- Defined in ?Data.Proxy? instance Monad Proxy -- Defined in ?Data.Proxy? instance Functor Proxy -- Defined in ?Data.Proxy? instance forall (k :: BOX) (s :: k). Ord (Proxy s) -- Defined in ?Data.Proxy? instance forall (k :: BOX) (s :: k). Read (Proxy s) -- Defined in ?Data.Proxy? instance forall (k :: BOX) (s :: k). Show (Proxy s) -- Defined in ?Data.Proxy? instance Applicative Proxy -- Defined in ?Data.Proxy? instance Foldable Proxy -- Defined in ?Data.Foldable? instance Traversable Proxy -- Defined in ?Data.Traversable? instance forall (k :: BOX) (s :: k). Monoid (Proxy s) -- Defined in ?Data.Proxy? even though you never enabled any extensions beyond what Haskell2010 provides. Do you consider this a bug as well? From m at tweag.io Mon Feb 15 11:51:23 2016 From: m at tweag.io (Boespflug, Mathieu) Date: Mon, 15 Feb 2016 12:51:23 +0100 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: <87si0u6y9h.fsf@smart-cactus.org> References: <87egcg93zn.fsf@smart-cactus.org> <1455381609.2134.16.camel@gmail.com> <87si0u6y9h.fsf@smart-cactus.org> Message-ID: > As far as I know, there is currently know way to > do this in 7.10. > > Given how much backlash there has been to changing the type of ($), ... Keep in mind... as we saw with FTP, that in this community it's often unclear just how large or tiny a group of people represent when they're vocal (could be an outright majority, could in fact be just a handful... hard to tell). ;) > I'd > be fine not using -fshow-runtime-rep during the core library haddock > builds. In effect the message to users would be, > > "yes, unboxed types exist and they are now on sound theoretical > footing, but they are still largely an implementation detail, just as > they have always been. If you want to use them you need to know > where to look." When that last sentence is expanded out a bit to explain what "know where to look means", it means "yes, unboxed types exist and they are now on sound theoretical footing [...]. If you want to use them you need to know where to look, i.e. pass -fshow-runtime-types to GHCi every time, and compile your own Haddock's, keep them safe somewhere on your computer and point your browser there instead, because https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ is not going to tell you where you can use it." All in a laudable effort to present less information to beginners out-of-the-box, IMHO the story is starting to look awefully complicated for Haskell practitioners, i.e. beginners-a-little-while-ago... Said another way, sounds to me like we're in a case of: avoiding surprise now begets bigger surprise later (and wasted time trying to discover all these myriad flags whose sole existence was to pretend to her/him that things are simpler than they really are, and then dealing with their consequences...) when the beginner becomes practitioner. > Perhaps this can be revisited at some point in the future when we have a > better story for a beginner's Prelude but for now I'm not sure we want > to subject everyone to these new types. TBH I'm fairly skeptical about the "Prelude for beginners" idea. Things like e.g. the AMP require that everyone has the same idea of what the definition of the Monad class is. Yet it's not like you're either a beginner or you're not: it's a continuum (we're all beginners, just some less than others...). When beginners start uploading new packages on Hackage (and I hope they do), but do so using BeginnerPrelude because that's what they were taught, then we start having to make the (artificially created) "beginner world" and the "real world" agree. If I define an instance of a BeginnerPrelude class in package A, it might not be exploitable in package B. Worse, if what we're really talking about is beginner-base, then what happens when they both define their own Data.List module? So in the end the scope of a BeginnerPrelude may be very limited indeed. If a beginner Prelude is really the right way forward, then surely one of the many authors of Haskell books would have put one forward by now and recommend using that? But perhaps this is a topic for another thread... -- Mathieu Boespflug Founder at http://tweag.io. From shumovichy at gmail.com Mon Feb 15 12:21:21 2016 From: shumovichy at gmail.com (Yuras Shumovich) Date: Mon, 15 Feb 2016 15:21:21 +0300 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: <87io1q435d.fsf@gmail.com> References: <87egcg93zn.fsf@smart-cactus.org> <1455381609.2134.16.camel@gmail.com> <1455534023.2134.35.camel@gmail.com> <87io1q435d.fsf@gmail.com> Message-ID: <1455538881.2134.52.camel@gmail.com> On Mon, 2016-02-15 at 12:35 +0100, Herbert Valerio Riedel wrote: > On 2016-02-15 at 12:00:23 +0100, Yuras Shumovich wrote: > > [...] > > > > - It is possible to have unlifted types about even without > > > -XMagicHash. -XMagicHash is simply a lexer extension, nothing > > > more. > > > By convention, we use the # suffix with unlifted things, but > > > there's > > > no requirement here. Having -XMagicHash thus imply a flag about > > > the > > > type system is bizarre. > > > > OK, I always forget about that. But is not it a bug already? > > Usually we > > don't allow code that uses GHC-specific extensions to compile > > without a > > language pragma. Why we don't have such pragma for levity > > polymorphism? > > There are extensions which are only needed at the definition > site. Take {-# LANGUAGE PolyKinds #-} for instance; this is enabled > inside the Data.Proxy module, which defines the following type > > ? {-# LANGUAGE PolyKinds #-} > ? module Data.Proxy where > > ? data Proxy t = Proxy > > Now when you query via GHCi 7.10, you get the following output > > ? > import Data.Proxy > ? > :i Proxy? > ? type role Proxy phantom > ? data Proxy (t :: k) = Proxy > ???? -- Defined in ?Data.Proxy? > ? instance forall (k :: BOX) (s :: k). Bounded (Proxy s) -- Defined > in ?Data.Proxy? > ? instance forall (k :: BOX) (s :: k). Enum (Proxy s) -- Defined in > ?Data.Proxy? > ? instance forall (k :: BOX) (s :: k). Eq (Proxy s) -- Defined in > ?Data.Proxy? > ? instance Monad Proxy -- Defined in ?Data.Proxy? > ? instance Functor Proxy -- Defined in ?Data.Proxy? > ? instance forall (k :: BOX) (s :: k). Ord (Proxy s) -- Defined in > ?Data.Proxy? > ? instance forall (k :: BOX) (s :: k). Read (Proxy s) -- Defined in > ?Data.Proxy? > ? instance forall (k :: BOX) (s :: k). Show (Proxy s) -- Defined in > ?Data.Proxy? > ? instance Applicative Proxy -- Defined in ?Data.Proxy? > ? instance Foldable Proxy -- Defined in ?Data.Foldable? > ? instance Traversable Proxy -- Defined in ?Data.Traversable? > ? instance forall (k :: BOX) (s :: k). Monoid (Proxy s) -- Defined in > ?Data.Proxy? > > even though you never enabled any extensions beyond what Haskell2010 > provides. > > Do you consider this a bug as well? Yes, IMO it is a bug. Though people didn't complain so far, so lets say it is a minor design flow. Probably there are more important bugs to fix. Ideally language extensions should not leak to Haskell2010. E.g. making lens using TemplateHaskell doens't leak to use side because I can define lens by hands and preserve the API. But if something can't be expressed in Haskell2010, then it should require extension to be enabled both of definition and use sides. In case of ($) people complain, and everybody seem to agree that levity polymorphism leaking to Haskell2010 is bad. Fixing the leakage IMO is the right way, while hiding the issue behind -fshow-rutime-rep is a hack and a lie. Probably the right way is harder in terms of development efforts (I have no idea). In that case it probably makes sense to choose easier way and introduce a hack. Life consists of compromises. From shumovichy at gmail.com Mon Feb 15 12:27:34 2016 From: shumovichy at gmail.com (Yuras Shumovich) Date: Mon, 15 Feb 2016 15:27:34 +0300 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: <1455538881.2134.52.camel@gmail.com> References: <87egcg93zn.fsf@smart-cactus.org> <1455381609.2134.16.camel@gmail.com> <1455534023.2134.35.camel@gmail.com> <87io1q435d.fsf@gmail.com> <1455538881.2134.52.camel@gmail.com> Message-ID: <1455539254.2134.55.camel@gmail.com> Ah, and I offer my help in case development efforts is the main concern. Though I'm not familiar with this part of GHC, so I'd need a mentor. My help probably will not be very useful, but I'd be happy to participate. On Mon, 2016-02-15 at 15:21 +0300, Yuras Shumovich wrote: > On Mon, 2016-02-15 at 12:35 +0100, Herbert Valerio Riedel wrote: > > On 2016-02-15 at 12:00:23 +0100, Yuras Shumovich wrote: > > > > [...] > > > > > > - It is possible to have unlifted types about even without > > > > -XMagicHash. -XMagicHash is simply a lexer extension, nothing > > > > more. > > > > By convention, we use the # suffix with unlifted things, but > > > > there's > > > > no requirement here. Having -XMagicHash thus imply a flag about > > > > the > > > > type system is bizarre. > > > > > > OK, I always forget about that. But is not it a bug already? > > > Usually we > > > don't allow code that uses GHC-specific extensions to compile > > > without a > > > language pragma. Why we don't have such pragma for levity > > > polymorphism? > > > > There are extensions which are only needed at the definition > > site. Take {-# LANGUAGE PolyKinds #-} for instance; this is enabled > > inside the Data.Proxy module, which defines the following type > > > > ? {-# LANGUAGE PolyKinds #-} > > ? module Data.Proxy where > > > > ? data Proxy t = Proxy > > > > Now when you query via GHCi 7.10, you get the following output > > > > ? > import Data.Proxy > > ? > :i Proxy? > > ? type role Proxy phantom > > ? data Proxy (t :: k) = Proxy > > ???? -- Defined in ?Data.Proxy? > > ? instance forall (k :: BOX) (s :: k). Bounded (Proxy s) -- Defined > > in ?Data.Proxy? > > ? instance forall (k :: BOX) (s :: k). Enum (Proxy s) -- Defined in > > ?Data.Proxy? > > ? instance forall (k :: BOX) (s :: k). Eq (Proxy s) -- Defined in > > ?Data.Proxy? > > ? instance Monad Proxy -- Defined in ?Data.Proxy? > > ? instance Functor Proxy -- Defined in ?Data.Proxy? > > ? instance forall (k :: BOX) (s :: k). Ord (Proxy s) -- Defined in > > ?Data.Proxy? > > ? instance forall (k :: BOX) (s :: k). Read (Proxy s) -- Defined in > > ?Data.Proxy? > > ? instance forall (k :: BOX) (s :: k). Show (Proxy s) -- Defined in > > ?Data.Proxy? > > ? instance Applicative Proxy -- Defined in ?Data.Proxy? > > ? instance Foldable Proxy -- Defined in ?Data.Foldable? > > ? instance Traversable Proxy -- Defined in ?Data.Traversable? > > ? instance forall (k :: BOX) (s :: k). Monoid (Proxy s) -- Defined > > in > > ?Data.Proxy? > > > > even though you never enabled any extensions beyond what > > Haskell2010 > > provides. > > > > Do you consider this a bug as well? > > Yes, IMO it is a bug. Though people didn't complain so far, so lets > say > it is a minor design flow. Probably there are more important bugs to > fix. > > Ideally language extensions should not leak to Haskell2010. E.g. > making > lens using TemplateHaskell doens't leak to use side because I can > define lens by hands and preserve the API. But if something can't be > expressed in Haskell2010, then it should require extension to be > enabled both of definition and use sides. > > In case of ($) people complain, and everybody seem to agree that > levity > polymorphism leaking to Haskell2010 is bad. Fixing the leakage IMO is > the right way, while hiding the issue behind -fshow-rutime-rep is a > hack and a lie. > > Probably the right way is harder in terms of development efforts (I > have no idea). In that case it probably makes sense to choose easier > way and introduce a hack. Life consists of compromises. > From dan.doel at gmail.com Mon Feb 15 13:40:56 2016 From: dan.doel at gmail.com (Dan Doel) Date: Mon, 15 Feb 2016 08:40:56 -0500 Subject: New type of expressions containing (error ...) includes noisy implicit parameter In-Reply-To: References: Message-ID: But that is a consequence of call stacks being implemented by threading a parameter through the calls, not of the fact that it shows up in the type. Without the change in type, the programmer wouldn't be informed there is any difference without looking at the core. In other words, this gives one reason why users _do_ care that stack information is being carried around, and might want to see it in the type; it can have a runtime performance impact (and likely not just for CAFs). -- Dan On Mon, Feb 15, 2016 at 5:12 AM, Simon Marlow wrote: > On 13 February 2016 at 08:32, Christopher Allen wrote: >> >> Prelude> let myList = [1, 2, 3 :: Integer] >> Prelude> let myList' = myList ++ undefined >> Prelude> :t myList >> myList :: [Integer] >> Prelude> :t myList' >> myList' :: (?callStack::GHC.Stack.Types.CallStack) => [Integer] > > > Yes, and I think perhaps an even more worrying problem here is that by > adding the reference to undefined, myList went from being a thunk to being a > function. That is, it will be re-evaluated each time it it used. I made a > ticket about this: https://ghc.haskell.org/trac/ghc/ticket/11383 > > Cheers > Simon > > >> >> This is on by default and insofar as I've been able to try, it's avoidable >> in a default GHCi 8.0 REPL session. I'm glad I caught this before our book >> goes to print in a couple months. We'd managed to avoid talking about >> implicit parameters in 1,100+ pages of book but now we're forced to >> acknowledge their existence in the 4th of 32 chapters. >> >> This slipped past the radar more stealthily than the earlier stages of BBP >> did for 7.10. I was hearing about BBP on the GHC Trac pretty early on for >> months on end. Was the thinking that people still used implicit parameters >> for anything or taught them? On the one hand, this is a nice change and >> something I personally attempted (and failed) to make easier in GHC 7.10. >> The implementation making the types noisy rankles and didn't seem necessary >> when I investigated it between 7.8 and 7.10. >> >> Could you warn us when (educationally relevant?) stuff like this is coming >> down the pipe before the RC please? Ideally during the design phase. I think >> this was discussed as part of FTP to avoid future debacles. >> >> This isn't just a pedagogical problem, this is a UX problem. The users >> don't _care_ that call stack information is being carried around. Why would >> they? It happens without any mention in the types in almost every other >> programming language. >> >> >> --- Chris Allen >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From eir at cis.upenn.edu Mon Feb 15 13:56:57 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 15 Feb 2016 08:56:57 -0500 Subject: Impredicative types and forall regression in 8.0 ? In-Reply-To: <56C1AD47.3020305@well-typed.com> References: <56C19E0D.6090506@snarc.org> <56C1AD47.3020305@well-typed.com> Message-ID: <2919D165-361E-410B-8015-E6066BBBB4EC@cis.upenn.edu> More generally, ImpredicativeTypes is utterly broken and has been for several release cycles. Sometimes, when you're lucky, it allows you to do something pretty neat. However, you need to hope that your luck remains strong between minor releases. It is an unsupported feature. I should note that TypeApplications required fairly serious surgery to the way type checking works. Given the general brokenness of ImpredicativeTypes, I didn't spend effort in trying to retain behavior with ImpredicativeTypes on. (I didn't actively try to make it worse, either.) It does not surprise me in the slightest that 8.0's ImpredicativeTypes is quite different from previous versions'. Richard On Feb 15, 2016, at 5:49 AM, Adam Gundry wrote: > Hi Vincent, > > On 15/02/16 09:44, Vincent Hanquez wrote: >> I recently came across a compilation problem on 8.0 that do not trigger >> on < 8.0. I've reduced the issue to this snippet with Rank2Types: >> >> type Action = (forall a . Show a => a) -> Int >> data Command = Command (Maybe Action) >> >> com1 = Command Nothing >> >> With GHC 7.0 to 7.10, this compile and works. > > This shouldn't be accepted without ImpredicativeTypes[*], but GHC > versions prior to 8.0 failed to look through the type synonym. Note that > if you say > > data Command = Command (Maybe ((forall a . Show a => a) -> Int)) > > then earlier versions report an error. Take a look at GHC ticket #10194 > for more details: https://ghc.haskell.org/trac/ghc/ticket/10194 > >> However on GHC 8.0, I now have: >> >> Test.hs:19:16: error: >> ? Cannot instantiate unification variable ?a0? >> with a type involving foralls: Action >> GHC doesn't yet support impredicative polymorphism >> ? In the first argument of ?Command?, namely ?Nothing? >> In the expression: Command Nothing >> In an equation for ?com1?: com1 = Command Nothing >> >> I workarounded it by "inlining" the maybe and creating a proper wrapping >> type: >> >> data Action2 = Action2 ((forall a . Show a => a) -> Int) | NoAction2 >> data Command2 = Command2 Action2 >> >> com2 = Command2 NoAction2 > > This looks like a reasonable alternative. > > Hope this helps, > > Adam > > [*] And if you turn on ImpredicativeTypes, GHC may or may not do the > right thing. > > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From ben at well-typed.com Mon Feb 15 14:09:32 2016 From: ben at well-typed.com (Ben Gamari) Date: Mon, 15 Feb 2016 15:09:32 +0100 Subject: Reconsidering -Wall and -Wcompat In-Reply-To: References: <87y4an6zjx.fsf@smart-cactus.org> Message-ID: <87k2m66p5v.fsf@smart-cactus.org> "Boespflug, Mathieu" writes: > Hi Ben, > > could we enlarge the options a bit? I feel that we're in a false > dichotomy currently. I think the issue isn't so much what warnings you > see from the compiler with common settings, so much as "what warnings > will cause my build to fail?". i.e. the issue isn't what's in -Wall, > it's what goes in -Werror... I can certainly see this point. As pointed out by Herbert, this is best provided by #11219 which unfortunately didn't make the 8.0 release. > If we don't include -Wcompat in -Wall, then I suspect Ben is quite > right that many will ignore / not be aware of -Wcompat hence rendering > the 3 release policy rather moot (it's much less useful if developers > don't /know/ they're incompatible until the last minute). If we do > include it then packages with -Wall -Werror will fail far too early: > i.e. way before the compat change actually happens, 3 compiler > releases down the line. So may I suggest the following: > > * include -Wcompat and -Wall, but make it "magic" so that -Wcompat > never causes a build to fail even when users set -Wall -Werror. > > This should address the concerns I've been hearing by folks at large > companies who say that at their company a warning is equivalent to an > error, because they always compile with -Wall -Werror. Otherwise > warnings just accumulate, hence no one pays attention to them, hence > warnings become useless. > > As an aside: I believe -Wall should do what it says on the tin: enable > all warnings. I am sympathetic to this argument. For better or for worse, however, there seems to be precedent for excluding some warnings in -Wall. Clang, for instance, uses -Weverything for "give me everything". Up until this point we have followed this model (although don't have a -Weverything); for instance, we disable -Wimplicit-prelude in -Wall since it is inappropriate for most users. I'm not sure whether we should break with this tradition as users are quite used to invoking their compiler with `-Wall` during development. Throwing warnings about implicit Prelude imports at them would be surprising to say the least. > When GHC comes up with new warnings, we should pretty > much never hesitate to add them to the -Wall set. I agree. This is why Simon wrote an explicit declaration that -Wall is not stable to the list a few weeks ago. We really don't want to worry about breaking builds of (potentially broken) user code when adding warnings. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From eir at cis.upenn.edu Mon Feb 15 14:14:47 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 15 Feb 2016 09:14:47 -0500 Subject: [Template Haskell] Desugaring TH brackets vs. Desugaring normal HsExprS. In-Reply-To: <87pow17sr8.fsf@t450s.i-did-not-set--mail-host-address--so-tickle-me> References: <87pow17sr8.fsf@t450s.i-did-not-set--mail-host-address--so-tickle-me> Message-ID: <3B5C2BE5-206A-4E1C-8469-BE4C8E3CAAE2@cis.upenn.edu> On Feb 12, 2016, at 12:17 PM, Dominik Bollmann wrote: > > Hi, > > I'm currently trying to understand GHC's implementation of Template > Haskell and I've had the following two questions when reading upon > deSugar/DsMeta.hs and deSugar/dsExpr.hs (disclaimer: I'm a complete > newbie to GHC and do not know pretty much anything about its internals; > so please excuse silly questions). > > 1) As far as I understand DsMeta, its purpose is to desugar the contents > of TH quotation brackets, e.g. [| \x -> x |]. Given the HsExpr contents, > say `expr`, of a quotation bracket, it creates a CoreExpr > /representation/ of `expr` such that /evaluating/ this CoreExpr > representation yields a TH expression equivalent to `expr`. (This is > similar to how quotations are implemented in the original TH paper). This sounds like one indirection too many. The desugared quote will be a CoreExpr that, when run, will produce the TH AST that matches the quote. > > On the other hand, when instead writing the above TH quote, (i.e., [| \x > -> x |]), explicitly as > > newName "x" >>= (\x -> lamE (varP x) (varE x)) (*) > > there is no need to build a CoreExpr /representation/ because we already > got the TH value we're interested in; Hence, in this case DsExpr > desugars the above (*) directly to a CoreExpr that represents it. > > Is my understanding of the above correct? I tried to confirm it using > the following to splices: > > test1 :: Q Exp > test1 = [| \x -> x |] > > test2 :: Q Exp > test2 = do > x <- newName "x" > lamE [(varP x)] (varE x) > > However, dumping the desugared output of these splices using `-ddump-ds` > gives the exact same CoreExprS: > > test1 :: Q Exp > [LclIdX, Str=DmdType] > test1 = > Language.Haskell.TH.Syntax.bindQ > @ Name > @ Exp > (newName (GHC.CString.unpackCString# "x"#)) > (\ (x_a399 :: Name) -> > lamE > (GHC.Types.: @ PatQ (varP x_a399) (GHC.Types.[] @ PatQ)) > (varE x_a399)) > > test2 :: Q Exp > [LclIdX, Str=DmdType] > test2 = >>> = > @ Q > Language.Haskell.TH.Syntax.$fMonadQ > @ Name > @ Exp > (newName (GHC.CString.unpackCString# "x"#)) > (\ (x_a39a :: Name) -> > lamE > (GHC.Types.: @ PatQ (varP x_a39a) (GHC.Types.[] @ PatQ)) > (varE x_a39a)) > > Could anyone explain to me why both CoreExpr dumps are the same? > Shouldn't the first be a /representation/ that, only when run, yields > the second CoreExpr? I'm not sure I understand why you think they should be different. What GHC is doing here seems correct to me; I would expect both tests to yield the same result. Sorry I can't be more helpful here! Richard From marlowsd at gmail.com Mon Feb 15 14:54:50 2016 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 15 Feb 2016 14:54:50 +0000 Subject: New type of expressions containing (error ...) includes noisy implicit parameter In-Reply-To: References: Message-ID: On 15 February 2016 at 13:40, Dan Doel wrote: > But that is a consequence of call stacks being implemented by > threading a parameter through the calls, not of the fact that it shows > up in the type. Without the change in type, the programmer wouldn't be > informed there is any difference without looking at the core. > I'm not suggesting that the parameter should be hidden in the type! I agree that would be much worse. No, I'm arguing that it was bad that we lost sharing just by using undefined (or error). If adding a call to error somewhere in your code changes its asymptotic performance, that's at the very least surprising. Apologies for diverting the discussion. I also think it's potentially bad from an educational point of view that error/undefined have these non-standard types, in fact I argued against using implicit call stacks in other functions in base for this reason (amongst others), and fortunately we've limited it to just these. Cheers Simon In other words, this gives one reason why users _do_ care that stack > information is being carried around, and might want to see it in the > type; it can have a runtime performance impact (and likely not just > for CAFs). > > -- Dan > > On Mon, Feb 15, 2016 at 5:12 AM, Simon Marlow wrote: > > On 13 February 2016 at 08:32, Christopher Allen > wrote: > >> > >> Prelude> let myList = [1, 2, 3 :: Integer] > >> Prelude> let myList' = myList ++ undefined > >> Prelude> :t myList > >> myList :: [Integer] > >> Prelude> :t myList' > >> myList' :: (?callStack::GHC.Stack.Types.CallStack) => [Integer] > > > > > > Yes, and I think perhaps an even more worrying problem here is that by > > adding the reference to undefined, myList went from being a thunk to > being a > > function. That is, it will be re-evaluated each time it it used. I > made a > > ticket about this: https://ghc.haskell.org/trac/ghc/ticket/11383 > > > > Cheers > > Simon > > > > > >> > >> This is on by default and insofar as I've been able to try, it's > avoidable > >> in a default GHCi 8.0 REPL session. I'm glad I caught this before our > book > >> goes to print in a couple months. We'd managed to avoid talking about > >> implicit parameters in 1,100+ pages of book but now we're forced to > >> acknowledge their existence in the 4th of 32 chapters. > >> > >> This slipped past the radar more stealthily than the earlier stages of > BBP > >> did for 7.10. I was hearing about BBP on the GHC Trac pretty early on > for > >> months on end. Was the thinking that people still used implicit > parameters > >> for anything or taught them? On the one hand, this is a nice change and > >> something I personally attempted (and failed) to make easier in GHC > 7.10. > >> The implementation making the types noisy rankles and didn't seem > necessary > >> when I investigated it between 7.8 and 7.10. > >> > >> Could you warn us when (educationally relevant?) stuff like this is > coming > >> down the pipe before the RC please? Ideally during the design phase. I > think > >> this was discussed as part of FTP to avoid future debacles. > >> > >> This isn't just a pedagogical problem, this is a UX problem. The users > >> don't _care_ that call stack information is being carried around. Why > would > >> they? It happens without any mention in the types in almost every other > >> programming language. > >> > >> > >> --- Chris Allen > >> > >> > >> _______________________________________________ > >> 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 svenpanne at gmail.com Mon Feb 15 17:32:31 2016 From: svenpanne at gmail.com (Sven Panne) Date: Mon, 15 Feb 2016 18:32:31 +0100 Subject: [ANNOUNCE] GHC 8.0.1 release candidate 2 In-Reply-To: <8737t49yof.fsf@smart-cactus.org> References: <8737t49yof.fsf@smart-cactus.org> Message-ID: I'm a little bit late to the 8.0.1 show, but nevertheless: Motivated by the current discussion about -Wcompat and friends I decided to take a detailed look at the warnings in my projects and hit a regression(?): Somehow I'm unable to suppress the "Top-level binding with no type signature" warnings from 8.0.1 onwards. The gory details: In my .cabal file I set -Wall ( https://github.com/haskell-opengl/OpenGLRaw/blob/master/OpenGLRaw.cabal#L618), and in my .travis.yml I set -Werror ( https://github.com/haskell-opengl/OpenGLRaw/blob/master/.travis.yml#L76). But the -Wno-missing-signatures pragma ( https://github.com/haskell-opengl/OpenGLRaw/blob/master/src/Graphics/GL/Tokens.hs#L2) doesn't work, see https://travis-ci.org/haskell-opengl/OpenGLRaw/jobs/109400373. Using -fno-warn-missing-signatures didn't work, either, see https://travis-ci.org/haskell-opengl/OpenGLRaw/jobs/109396738. Am I doing something wrong here or is this really a regression? I'm quite sure that suppressions via pragmas worked in the past... :-( Cheers, S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Mon Feb 15 17:55:05 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 15 Feb 2016 12:55:05 -0500 Subject: quick performance measurements In-Reply-To: <1455312686.3543.14.camel@joachim-breitner.de> References: <5A53015C-3260-461D-826E-18F85903C289@cis.upenn.edu> <1455312686.3543.14.camel@joachim-breitner.de> Message-ID: I realized there is a very simple way to do what I want: --make +RTS -s Specifically, I've arbitrarily chosen compiling Cabal as a test case, saying > ghc-stage2 Distribution/*.hs Distribution/*/*.hs --make -fforce-recomp +RTS -s and seeing what I get. Richard On Feb 12, 2016, at 4:31 PM, Joachim Breitner wrote: > Hi, > > Am Freitag, den 12.02.2016, 14:04 -0500 schrieb Richard Eisenberg: >> Ideally, there would be a way to run a portion of the testsuite and >> have the testsuite tool aggregate performance characteristics and >> report. > > if you run the test suite with > $ VERBOSE=4 > you get the detailed stats for every perf test, not only for the > failing ones. This is what the gipeda runner does. > > You?d still have to manually compare them, though; no aggregation > happening. > > Also, the compiler perf test cases usually check one specific extreme > code path, so they are not a good measure of real world performance. > nofib is better there, and has comparing integrated, but only checks > those parts of the compiler that deal with idiomatic Haskell code from > 10 or 20 years back. > > Maybe I should write a text that explains how to run gipeda locally on > a bunch of commits on a local branch... but it?s only making the > results more shiny, not more significant, than running nofib or the > test suite manually. > > Greetings, > Joachim > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? https://www.joachim-breitner.de/ > XMPP: nomeata at joachim-breitner.de ? OpenPGP-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 smart-cactus.org Mon Feb 15 19:16:24 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 15 Feb 2016 20:16:24 +0100 Subject: [ANNOUNCE] GHC 8.0.1 release candidate 2 In-Reply-To: References: <8737t49yof.fsf@smart-cactus.org> Message-ID: <87fuwt7piv.fsf@smart-cactus.org> Sven Panne writes: > I'm a little bit late to the 8.0.1 show, but nevertheless: Motivated by the > current discussion about -Wcompat and friends I decided to take a detailed > look at the warnings in my projects and hit a regression(?): Somehow I'm > unable to suppress the "Top-level binding with no type signature" warnings > from 8.0.1 onwards. > > The gory details: In my .cabal file I set -Wall ( > https://github.com/haskell-opengl/OpenGLRaw/blob/master/OpenGLRaw.cabal#L618), > and in my .travis.yml I set -Werror ( > https://github.com/haskell-opengl/OpenGLRaw/blob/master/.travis.yml#L76). > But the -Wno-missing-signatures pragma ( > https://github.com/haskell-opengl/OpenGLRaw/blob/master/src/Graphics/GL/Tokens.hs#L2) > doesn't work, see > https://travis-ci.org/haskell-opengl/OpenGLRaw/jobs/109400373. Using > -fno-warn-missing-signatures didn't work, either, see > https://travis-ci.org/haskell-opengl/OpenGLRaw/jobs/109396738. > > Am I doing something wrong here or is this really a regression? I'm quite > sure that suppressions via pragmas worked in the past... :-( > The reason for this is that the things missing signatures are pattern synonyms, which have their warnings controlled by -Wmissing-pat-syn-sigs [1], which is enabled in -Wall by default. Cheers, - Ben [1] http://downloads.haskell.org/~ghc/master/users-guide//using-warnings.html#ghc-flag--Wmissing-pat-syn-sigs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From svenpanne at gmail.com Mon Feb 15 20:05:29 2016 From: svenpanne at gmail.com (Sven Panne) Date: Mon, 15 Feb 2016 21:05:29 +0100 Subject: [ANNOUNCE] GHC 8.0.1 release candidate 2 In-Reply-To: <87fuwt7piv.fsf@smart-cactus.org> References: <8737t49yof.fsf@smart-cactus.org> <87fuwt7piv.fsf@smart-cactus.org> Message-ID: 2016-02-15 20:16 GMT+01:00 Ben Gamari : > Sven Panne writes: > The reason for this is that the things missing signatures are pattern > synonyms, which have their warnings controlled by -Wmissing-pat-syn-sigs > [1], which is enabled in -Wall by default. > OK, I missed that in the release notes. Two points here: * The naming of the options is horrible, sometimes it's "sigs", sometimes it's "signatures". I would prefer if we named them consistently (probably "signatures", it's easier to search for). * Given the myriad of warning-related options, It is *extremely* hard to figure out which one caused the actual warning in question. The solution to this is very easy and done this way in clang/gcc (don't remember which one, I'm switching quite often): Just suffix all warnings consistently with the option causing it, e.g. Top-level binding with no type signature: [ -Wmissing-pat-syn-sigs]: Cheers, S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Mon Feb 15 20:11:57 2016 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Mon, 15 Feb 2016 21:11:57 +0100 Subject: [ANNOUNCE] GHC 8.0.1 release candidate 2 In-Reply-To: (Sven Panne's message of "Mon, 15 Feb 2016 21:05:29 +0100") References: <8737t49yof.fsf@smart-cactus.org> <87fuwt7piv.fsf@smart-cactus.org> Message-ID: <878u2l4tte.fsf@gmail.com> On 2016-02-15 at 21:05:29 +0100, Sven Panne wrote: [...] > * Given the myriad of warning-related options, It is *extremely* hard to > figure out which one caused the actual warning in question. The solution to > this is very easy and done this way in clang/gcc (don't remember which one, > I'm switching quite often): Just suffix all warnings consistently with the > option causing it, e.g. > > Top-level binding with no type signature: [ -Wmissing-pat-syn-sigs]: > Fyi, https://ghc.haskell.org/trac/ghc/wiki/Design/Warnings and specifically https://ghc.haskell.org/trac/ghc/ticket/10752 :-) From ben at smart-cactus.org Mon Feb 15 21:09:52 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 15 Feb 2016 22:09:52 +0100 Subject: [ANNOUNCE] GHC 8.0.1 release candidate 2 In-Reply-To: References: <8737t49yof.fsf@smart-cactus.org> <87fuwt7piv.fsf@smart-cactus.org> Message-ID: <87a8n17k9r.fsf@smart-cactus.org> Sven Panne writes: > 2016-02-15 20:16 GMT+01:00 Ben Gamari : > >> Sven Panne writes: >> The reason for this is that the things missing signatures are pattern >> synonyms, which have their warnings controlled by -Wmissing-pat-syn-sigs >> [1], which is enabled in -Wall by default. >> > > OK, I missed that in the release notes. Two points here: > > * The naming of the options is horrible, sometimes it's "sigs", > sometimes it's "signatures". I would prefer if we named them consistently > (probably "signatures", it's easier to search for). > Indeed, I noticed that this when looking this up for you. The inconsistency is quite unfortunate. Perhaps -Wmissing-pattern-signatures or -Wmissing-patsyn-signatures? -Wmissing-pattern-synonym-signatures is a bit of a mouthful. > * Given the myriad of warning-related options, It is *extremely* hard to > figure out which one caused the actual warning in question. The solution to > this is very easy and done this way in clang/gcc (don't remember which one, > I'm switching quite often): Just suffix all warnings consistently with the > option causing it, e.g. > Indeed, this is #10752, as hvr pointed out. I'm not sure whether David has done anything on this yet; feel free to take a stab at implementing it if you have some free time. - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From matthewtpickering at gmail.com Mon Feb 15 23:35:06 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Mon, 15 Feb 2016 23:35:06 +0000 Subject: [ANNOUNCE] GHC 8.0.1 release candidate 2 In-Reply-To: <87a8n17k9r.fsf@smart-cactus.org> References: <8737t49yof.fsf@smart-cactus.org> <87fuwt7piv.fsf@smart-cactus.org> <87a8n17k9r.fsf@smart-cactus.org> Message-ID: Hello, I have renamed it to -Wmissing-pat-syn-signatures. Matt On Mon, Feb 15, 2016 at 9:09 PM, Ben Gamari wrote: > Sven Panne writes: > >> 2016-02-15 20:16 GMT+01:00 Ben Gamari : >> >>> Sven Panne writes: >>> The reason for this is that the things missing signatures are pattern >>> synonyms, which have their warnings controlled by -Wmissing-pat-syn-sigs >>> [1], which is enabled in -Wall by default. >>> >> >> OK, I missed that in the release notes. Two points here: >> >> * The naming of the options is horrible, sometimes it's "sigs", >> sometimes it's "signatures". I would prefer if we named them consistently >> (probably "signatures", it's easier to search for). >> > Indeed, I noticed that this when looking this up for you. The > inconsistency is quite unfortunate. Perhaps -Wmissing-pattern-signatures > or -Wmissing-patsyn-signatures? -Wmissing-pattern-synonym-signatures is > a bit of a mouthful. > >> * Given the myriad of warning-related options, It is *extremely* hard to >> figure out which one caused the actual warning in question. The solution to >> this is very easy and done this way in clang/gcc (don't remember which one, >> I'm switching quite often): Just suffix all warnings consistently with the >> option causing it, e.g. >> > Indeed, this is #10752, as hvr pointed out. I'm not sure whether David > has done anything on this yet; feel free to take a stab at implementing > it if you have some free time. > > - Ben > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From chak at justtesting.org Tue Feb 16 00:30:26 2016 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Tue, 16 Feb 2016 11:30:26 +1100 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: <87si0u6y9h.fsf@smart-cactus.org> References: <87egcg93zn.fsf@smart-cactus.org> <1455381609.2134.16.camel@gmail.com> <87si0u6y9h.fsf@smart-cactus.org> Message-ID: > Ben Gamari : > builds. In effect the message to users would be, > > "yes, unboxed types exist and they are now on sound theoretical > footing, but they are still largely an implementation detail, just as > they have always been. If you want to use them you need to know > where to look." > > Perhaps this can be revisited at some point in the future when we have a > better story for a beginner's Prelude but for now I'm not sure we want > to subject everyone to these new types. > > Anyways, this is just my two cents. It would be nice to hear what others > think. Sounds like a good plan to me. Manuel From cma at bitemyapp.com Tue Feb 16 00:35:29 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Mon, 15 Feb 2016 18:35:29 -0600 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: References: <87egcg93zn.fsf@smart-cactus.org> <1455381609.2134.16.camel@gmail.com> <87si0u6y9h.fsf@smart-cactus.org> Message-ID: I don't think it's a good idea to create a dumbed down Prelude and existing resources not covering what programmers need to know in order to actually use Haskell as everyone else uses it is much of the reason I had to write a book to begin with. This type isn't just noise for beginners, it's noise for practitioners too. Consider what I said earlier about a 15 year user of Haskell finding the type confusing and irrelevant. There are a couple good proposals for addressing levity polymorphism leaking into the type. I think the one Ben Gamari had in mind that I thought would be fine is waiting for a patch. On Mon, Feb 15, 2016 at 6:30 PM, Manuel M T Chakravarty < chak at justtesting.org> wrote: > > Ben Gamari : > > builds. In effect the message to users would be, > > > > "yes, unboxed types exist and they are now on sound theoretical > > footing, but they are still largely an implementation detail, just as > > they have always been. If you want to use them you need to know > > where to look." > > > > Perhaps this can be revisited at some point in the future when we have a > > better story for a beginner's Prelude but for now I'm not sure we want > > to subject everyone to these new types. > > > > Anyways, this is just my two cents. It would be nice to hear what others > > think. > > Sounds like a good plan to me. > > Manuel > > _______________________________________________ > 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 svenpanne at gmail.com Tue Feb 16 07:00:49 2016 From: svenpanne at gmail.com (Sven Panne) Date: Tue, 16 Feb 2016 08:00:49 +0100 Subject: [ANNOUNCE] GHC 8.0.1 release candidate 2 In-Reply-To: References: <8737t49yof.fsf@smart-cactus.org> <87fuwt7piv.fsf@smart-cactus.org> <87a8n17k9r.fsf@smart-cactus.org> Message-ID: 2016-02-16 0:35 GMT+01:00 Matthew Pickering : > I have renamed it to -Wmissing-pat-syn-signatures. > Hmmm, things are still wildly inconsistent: * "pat" is spelled "pattern" in other flags. * We still have both "sigs" and "signatures" as parts of the names. * Why is "synonyms" too long, but OTOH we have monsters like "-Wnoncanonical-monadfail-instances"? * We have both "binds" and "bindings" as parts of the names. My proposal would be: The -Wfoo option syntax is new, anyway, so let's fix all those inconsistencies in one big sweep before 8.0.1 is out, it only gets harder later. At the moment you need #ifdef magic in the code and "If impl(foo)" in .cabal, anyway, but doing these changes later will only keep this sorry state for longer than necessary. I don't really care if we use abbreviations like "sigs" or not, but whatever we use, we should use it consistently (personally I would prefer the whole words, not the abbreviations). Cheers, S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.kjeldaas at gmail.com Tue Feb 16 07:28:30 2016 From: alexander.kjeldaas at gmail.com (Alexander Kjeldaas) Date: Tue, 16 Feb 2016 08:28:30 +0100 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: References: <0210F72D-CCF3-452A-BAD4-15796F288FD9@justtesting.org> <1454628457-sup-7751@sabre> <56B44DCE.5010602@ro-che.info> <1454663966.1570.1.camel@joachim-breitner.de> Message-ID: On Fri, Feb 5, 2016 at 2:16 PM, Takenobu Tani wrote: > Hi, > > I'll worry about the learning curve of beginners. > Maybe, beginners will try following session in their 1st week. > > ghci> :t foldr > ghci> :t ($) > > They'll get following result. > > > Before ghc7.8: > > Prelude> :t foldr > foldr :: (a -> b -> b) -> b -> [a] -> b > > Prelude> :t ($) > ($) :: (a -> b) -> a -> b > > Beginners should only understand about following: > > * type variable (polymorphism) > > > After ghc8.0: > > Prelude> :t foldr > foldr :: Foldable t => (a -> b -> b) -> b -> t a -> b > > If the output was the following it would be more understandable (and more encouraging!) """ Prelude> :t foldr foldr :: Foldable t => (a -> b -> b) -> b -> t a -> b For example: foldr :: (a -> b -> b) -> b -> [a] -> b foldr :: (a -> b -> b) -> b -> Maybe a -> b foldr :: (a -> b -> b) -> b -> Identity a -> b foldr :: (a -> b -> b) -> b -> (c, a) -> b and more """ It is easy to see a pattern here. The order of the instances used could be the load order, so the ones from Prelude would come first. > Prelude> :t ($) > ($) > :: forall (w :: GHC.Types.Levity) a (b :: TYPE w). > (a -> b) -> a -> b > > I'm not sure how this would work here, but when Levity is *, this should collapse into the old syntax, so: """ Prelude> :t ($) ($) :: <"unreadable blurb"> For example: ($) :: (a -> b) -> a -> b ($) :: forall a (b :: #). (a -> b) -> a -> b """ At least one of those lines should be understandable. Alexander -------------- next part -------------- An HTML attachment was scrubbed... URL: From tab at snarc.org Tue Feb 16 07:43:25 2016 From: tab at snarc.org (Vincent Hanquez) Date: Tue, 16 Feb 2016 07:43:25 +0000 Subject: Impredicative types and forall regression in 8.0 ? In-Reply-To: <56C1AD47.3020305@well-typed.com> References: <56C19E0D.6090506@snarc.org> <56C1AD47.3020305@well-typed.com> Message-ID: <56C2D31D.3080700@snarc.org> On 15/02/2016 10:49, Adam Gundry wrote: > Hi Vincent, > > On 15/02/16 09:44, Vincent Hanquez wrote: >> I recently came across a compilation problem on 8.0 that do not trigger >> on < 8.0. I've reduced the issue to this snippet with Rank2Types: >> >> type Action = (forall a . Show a => a) -> Int >> data Command = Command (Maybe Action) >> >> com1 = Command Nothing >> >> With GHC 7.0 to 7.10, this compile and works. > This shouldn't be accepted without ImpredicativeTypes[*], but GHC > versions prior to 8.0 failed to look through the type synonym. Note that > if you say > > data Command = Command (Maybe ((forall a . Show a => a) -> Int)) > > then earlier versions report an error. Take a look at GHC ticket #10194 > for more details: https://ghc.haskell.org/trac/ghc/ticket/10194 Ok, make sense; After reading what ImpredicativeTypes are, I can see the difference in the construct. Thanks, -- Vincent From simonpj at microsoft.com Tue Feb 16 09:42:47 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 16 Feb 2016 09:42:47 +0000 Subject: [ANNOUNCE] GHC 8.0.1 release candidate 2 In-Reply-To: References: <8737t49yof.fsf@smart-cactus.org> <87fuwt7piv.fsf@smart-cactus.org> <87a8n17k9r.fsf@smart-cactus.org> Message-ID: <533bfe1d7626472baeca3de2b4de1f40@DB4PR30MB030.064d.mgd.msft.net> I?m all for it. We could add the new spellings as synonyms of the old ones; and deprecate old ones. Then drop the old ones after a release cycle or three Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Sven Panne Sent: 16 February 2016 07:01 To: GHC developers Subject: Re: [ANNOUNCE] GHC 8.0.1 release candidate 2 2016-02-16 0:35 GMT+01:00 Matthew Pickering >: I have renamed it to -Wmissing-pat-syn-signatures. Hmmm, things are still wildly inconsistent: * "pat" is spelled "pattern" in other flags. * We still have both "sigs" and "signatures" as parts of the names. * Why is "synonyms" too long, but OTOH we have monsters like "-Wnoncanonical-monadfail-instances"? * We have both "binds" and "bindings" as parts of the names. My proposal would be: The -Wfoo option syntax is new, anyway, so let's fix all those inconsistencies in one big sweep before 8.0.1 is out, it only gets harder later. At the moment you need #ifdef magic in the code and "If impl(foo)" in .cabal, anyway, but doing these changes later will only keep this sorry state for longer than necessary. I don't really care if we use abbreviations like "sigs" or not, but whatever we use, we should use it consistently (personally I would prefer the whole words, not the abbreviations). Cheers, S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Tue Feb 16 09:49:02 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 16 Feb 2016 10:49:02 +0100 Subject: [ANNOUNCE] GHC 8.0.1 release candidate 2 In-Reply-To: References: <8737t49yof.fsf@smart-cactus.org> <87fuwt7piv.fsf@smart-cactus.org> <87a8n17k9r.fsf@smart-cactus.org> Message-ID: <874md96l4h.fsf@smart-cactus.org> Sven Panne writes: > 2016-02-16 0:35 GMT+01:00 Matthew Pickering : > >> I have renamed it to -Wmissing-pat-syn-signatures. >> > > Hmmm, things are still wildly inconsistent: > > * "pat" is spelled "pattern" in other flags. > > * We still have both "sigs" and "signatures" as parts of the names. > > * Why is "synonyms" too long, but OTOH we have monsters like > "-Wnoncanonical-monadfail-instances"? > > * We have both "binds" and "bindings" as parts of the names. > > My proposal would be: The -Wfoo option syntax is new, anyway, so let's fix > all those inconsistencies in one big sweep before 8.0.1 is out, it only > gets harder later. At the moment you need #ifdef magic in the code and "If > impl(foo)" in .cabal, anyway, but doing these changes later will only keep > this sorry state for longer than necessary. I don't really care if we use > abbreviations like "sigs" or not, but whatever we use, we should use it > consistently (personally I would prefer the whole words, not the > abbreviations). > Fair enough; since we are are breaking away from -fwarn- we could consider taking this opportunity to fix these inconsistencies. However, I do want to make sure that we don't make the transition any more painful for users than necessary. For instance, the user should be able to get useful feedback from the compiler on what warning flags have changed with s/-fwarn-/-W/ To this end I recommend the following, * Someone propose a consistent vocabulary for warning flag names * We keep -fwarn- flags as they are currently * We keep the inconsistently named -W flags corresponding to these -fwarn- flags * We add consistently named -W flags alongside these * We set a timeline for deprecating the inconsistent flags Sven, perhaps you would like to pick up this task? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From hvriedel at gmail.com Tue Feb 16 09:56:22 2016 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Tue, 16 Feb 2016 10:56:22 +0100 Subject: [ANNOUNCE] GHC 8.0.1 release candidate 2 In-Reply-To: (Sven Panne's message of "Tue, 16 Feb 2016 08:00:49 +0100") References: <8737t49yof.fsf@smart-cactus.org> <87fuwt7piv.fsf@smart-cactus.org> <87a8n17k9r.fsf@smart-cactus.org> Message-ID: <87vb5p0yih.fsf@gmail.com> On 2016-02-16 at 08:00:49 +0100, Sven Panne wrote: >> I have renamed it to -Wmissing-pat-syn-signatures. >> > > Hmmm, things are still wildly inconsistent: > > * "pat" is spelled "pattern" in other flags. > > * We still have both "sigs" and "signatures" as parts of the names. I simple head-count in GHC HEAD: -ddump-strsigs -Wmissing-local-sigs -Wmissing-exported-sigs vs -dsuppress-type-signatures -Wmissing-signatures -Wpartial-type-signatures at this point I'd be fine with either -Wmissing-pattern-synonyms-signatures or even -Wmissing-pattern-synonyms-sigs as neither 'pattern' nor 'synonym` have any abbreviation precedent in `ghc --show-options`, but `sig(nature)s` has a precedent, so using `-sigs` wouldn't introduce anything new. > * Why is "synonyms" too long, but OTOH we have monsters like > "-Wnoncanonical-monadfail-instances"? Well... the -Wnoncanonical-*-instances flag family was the best I could come up with which is reasonably self-descriptive... do you have any better suggestions? > * We have both "binds" and "bindings" as parts of the names. Fwiw, `ghc --show-options | grep binding` come ups empty From ben at smart-cactus.org Tue Feb 16 10:35:51 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 16 Feb 2016 11:35:51 +0100 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: References: <87egcg93zn.fsf@smart-cactus.org> <1455381609.2134.16.camel@gmail.com> <87si0u6y9h.fsf@smart-cactus.org> Message-ID: <8737st6iyg.fsf@smart-cactus.org> "Boespflug, Mathieu" writes: >> As far as I know, there is currently know way to >> do this in 7.10. >> >> Given how much backlash there has been to changing the type of ($), ... > > Keep in mind... as we saw with FTP, that in this community it's often > unclear just how large or tiny a group of people represent when > they're vocal (could be an outright majority, could in fact be just a > handful... hard to tell). ;) > This is very true. I wish we had better instruments for judging consensus. Sadly it seems this is a problem that has long resisted solution. >> I'd be fine not using -fshow-runtime-rep during the core library >> haddock builds. In effect the message to users would be, >> >> "yes, unboxed types exist and they are now on sound theoretical >> footing, but they are still largely an implementation detail, just as >> they have always been. If you want to use them you need to know >> where to look." > > When that last sentence is expanded out a bit to explain what "know > where to look means", it means > > "yes, unboxed types exist and they are now on sound theoretical > footing [...]. If you want to use them you need to know where to look, > i.e. pass -fshow-runtime-types to GHCi every time, and compile your > own Haddock's, keep them safe somewhere on your computer and point > your browser there instead, because > https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ is not > going to tell you where you can use it." > > All in a laudable effort to present less information to beginners > out-of-the-box, IMHO the story is starting to look awefully > complicated for Haskell practitioners, i.e. > beginners-a-little-while-ago... > Well said. > Said another way, sounds to me like we're in a case of: avoiding > surprise now begets bigger surprise later (and wasted time trying to > discover all these myriad flags whose sole existence was to pretend to > her/him that things are simpler than they really are, and then dealing > with their consequences...) when the beginner becomes practitioner. > Sure, but there is a trade-off here. Even in performance-sensitive applications unboxed types don't appear that frequently. Now, perhaps this will change as these types become well-behaved members of the language. However at the moment I'm not convinced that the consistency that showing this polymorphism to all users pays for itself. Afterall, the signatures are significantly noiser than the current monomorphic forms. However, I think we should certainly reconsider this once we have had some experience working with these types in the post-levity-polymorphic world and have worked out how to deal with some of the more human issues that they bring. >> Perhaps this can be revisited at some point in the future when we have a >> better story for a beginner's Prelude but for now I'm not sure we want >> to subject everyone to these new types. > > TBH I'm fairly skeptical about the "Prelude for beginners" idea. > Things like e.g. the AMP require that everyone has the same idea of > what the definition of the Monad class is. Yet it's not like you're > either a beginner or you're not: it's a continuum (we're all > beginners, just some less than others...). When beginners start > uploading new packages on Hackage (and I hope they do), but do so > using BeginnerPrelude because that's what they were taught, then we > start having to make the (artificially created) "beginner world" and > the "real world" agree. If I define an instance of a BeginnerPrelude > class in package A, it might not be exploitable in package B. Worse, > if what we're really talking about is beginner-base, then what happens > when they both define their own Data.List module? So in the end the > scope of a BeginnerPrelude may be very limited indeed. > > If a beginner Prelude is really the right way forward, then surely one > of the many authors of Haskell books would have put one forward by now > and recommend using that? > > But perhaps this is a topic for another thread... > Indeed. I'll just say that I envision that a beginner's prelude would be for learning and nothing more. The goal is that it would be used in the first dozen hours of picking up the language and nothing more. I'd be interested to hear what Richard had in mind when he has time again. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From svenpanne at gmail.com Tue Feb 16 10:45:17 2016 From: svenpanne at gmail.com (Sven Panne) Date: Tue, 16 Feb 2016 11:45:17 +0100 Subject: [ANNOUNCE] GHC 8.0.1 release candidate 2 In-Reply-To: <87vb5p0yih.fsf@gmail.com> References: <8737t49yof.fsf@smart-cactus.org> <87fuwt7piv.fsf@smart-cactus.org> <87a8n17k9r.fsf@smart-cactus.org> <87vb5p0yih.fsf@gmail.com> Message-ID: 2016-02-16 10:56 GMT+01:00 Herbert Valerio Riedel : > [...] but `sig(nature)s` has a precedent, so using `-sigs` wouldn't > introduce anything new. > I'm fine with "sigs", my point was only the fact that non-abbreviated words seem to be much more common in the flags names (and are easier to remember). IMHO it doesn't really matter if the flag names are long: One probably doesn't type them on the command line often, they typically live in .cabal files, .travis.yml and pragmas where you type them once. Well... the -Wnoncanonical-*-instances flag family was the best I could > come up with which is reasonably self-descriptive... do you have any > better suggestions? > No, and I actually like the long names, see above. :-) > Fwiw, `ghc --show-options | grep binding` come ups empty > Then the docs are out-of-sync: http://downloads.haskell.org/~ghc/master/users-guide/using-warnings.html#ghc-flag--Wlazy-unlifted-bindings -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Tue Feb 16 10:57:49 2016 From: svenpanne at gmail.com (Sven Panne) Date: Tue, 16 Feb 2016 11:57:49 +0100 Subject: [ANNOUNCE] GHC 8.0.1 release candidate 2 In-Reply-To: <874md96l4h.fsf@smart-cactus.org> References: <8737t49yof.fsf@smart-cactus.org> <87fuwt7piv.fsf@smart-cactus.org> <87a8n17k9r.fsf@smart-cactus.org> <874md96l4h.fsf@smart-cactus.org> Message-ID: 2016-02-16 10:49 GMT+01:00 Ben Gamari : > [...] To this end I recommend the following, > > * Someone propose a consistent vocabulary for warning flag names > > * We keep -fwarn- flags as they are currently > > * We keep the inconsistently named -W flags corresponding to these > -fwarn- flags > > * We add consistently named -W flags alongside these > > * We set a timeline for deprecating the inconsistent flags > This plan looks perfect. > Sven, perhaps you would like to pick up this task? > Alas, I don't have many spare development cycles at the moment, especially given the relatively tight timeline for 8.0.1. I have just enough time to grumble about some GHC details on this list. ;-) More seriously, after Herbert's option survey my proposal is quite short: * Use "sigs" or "signatures" consistently (doesn't really matter which one) * Use "pattern-synonyms", not "pat-syn" -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Tue Feb 16 11:01:29 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 16 Feb 2016 12:01:29 +0100 Subject: [ANNOUNCE] GHC 8.0.1 release candidate 2 In-Reply-To: References: <8737t49yof.fsf@smart-cactus.org> <87fuwt7piv.fsf@smart-cactus.org> <87a8n17k9r.fsf@smart-cactus.org> <87vb5p0yih.fsf@gmail.com> Message-ID: <87wpq46hrq.fsf@smart-cactus.org> Sven Panne writes: > 2016-02-16 10:56 GMT+01:00 Herbert Valerio Riedel : > >> [...] but `sig(nature)s` has a precedent, so using `-sigs` wouldn't >> introduce anything new. >> > > I'm fine with "sigs", my point was only the fact that non-abbreviated words > seem to be much more common in the flags names (and are easier to > remember). IMHO it doesn't really matter if the flag names are long: One > probably doesn't type them on the command line often, they typically live > in .cabal files, .travis.yml and pragmas where you type them once. > > Well... the -Wnoncanonical-*-instances flag family was the best I could >> come up with which is reasonably self-descriptive... do you have any >> better suggestions? >> > > No, and I actually like the long names, see above. :-) I don't have an opinion here. Especially with tab completion these names are rarely typed anyways. >> Fwiw, `ghc --show-options | grep binding` come ups empty >> > > Then the docs are out-of-sync: > http://downloads.haskell.org/~ghc/master/users-guide/using-warnings.html#ghc-flag--Wlazy-unlifted-bindings Indeed it appears that this warning was supposed to be removed in 7.10. I've gone ahead and finished this in https://phabricator.haskell.org/D1922 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 Feb 16 11:02:51 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 16 Feb 2016 12:02:51 +0100 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: References: <87egcg93zn.fsf@smart-cactus.org> <1455381609.2134.16.camel@gmail.com> <87si0u6y9h.fsf@smart-cactus.org> Message-ID: <87vb5o6hpg.fsf@smart-cactus.org> Christopher Allen writes: > I don't think it's a good idea to create a dumbed down Prelude and existing > resources not covering what programmers need to know in order to actually > use Haskell as everyone else uses it is much of the reason I had to write a > book to begin with. This type isn't just noise for beginners, it's noise > for practitioners too. Consider what I said earlier about a 15 year user of > Haskell finding the type confusing and irrelevant. I agree that until we have shown that these polymorphic uses offer real value in common use-cases we shouldn't allow them to add noise to our common combinator types. > There are a couple good proposals for addressing levity polymorphism > leaking into the type. I think the one Ben Gamari had in mind that I > thought would be fine is waiting for a patch. > I believe this is on Richard's todo list. 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 Feb 16 11:44:35 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 16 Feb 2016 12:44:35 +0100 Subject: [ANNOUNCE] GHC 8.0.1 release candidate 2 In-Reply-To: References: <8737t49yof.fsf@smart-cactus.org> <87fuwt7piv.fsf@smart-cactus.org> <87a8n17k9r.fsf@smart-cactus.org> <874md96l4h.fsf@smart-cactus.org> Message-ID: <87r3gc6frw.fsf@smart-cactus.org> Ccing quchen who has been working on warning-related things. Sven Panne writes: > 2016-02-16 10:49 GMT+01:00 Ben Gamari : > >> [...] To this end I recommend the following, >> >> * Someone propose a consistent vocabulary for warning flag names >> >> * We keep -fwarn- flags as they are currently >> >> * We keep the inconsistently named -W flags corresponding to these >> -fwarn- flags >> >> * We add consistently named -W flags alongside these >> >> * We set a timeline for deprecating the inconsistent flags >> > > This plan looks perfect. Great! >> Sven, perhaps you would like to pick up this task? >> > > Alas, I don't have many spare development cycles at the moment, especially > given the relatively tight timeline for 8.0.1. I'm afraid I also don't have the bandwidth to pick this up. I have opened #11583 to track this issue. I hope someone is able to pick this up before the release. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ben at well-typed.com Tue Feb 16 13:44:34 2016 From: ben at well-typed.com (Ben Gamari) Date: Tue, 16 Feb 2016 14:44:34 +0100 Subject: Installing Cabal for GHC 8.0 release candidates Message-ID: <87mvr06a7x.fsf@smart-cactus.org> Hello everyone, Our wonderful Cabal release manager Mikhail Glushenkov has kindly uploaded candidate releases of Cabal and cabal-install for use by GHC 8.0 release candidate users. Now updating to a GHC 8.0-compatible Cabal/cabal-install should be as simple as, cabal install \ http://hackage.haskell.org/package/Cabal-1.23.1.0/candidate/Cabal-1.23.1.0.tar.gz \ http://hackage.haskell.org/package/cabal-install-1.23.0.0/candidate/cabal-install-1.23.0.0.tar.gz Happy testing! 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 Feb 16 13:49:27 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 16 Feb 2016 13:49:27 +0000 Subject: Is anything being done to remedy the soul crushing compile times of GHC? In-Reply-To: <4E06663C-C48C-4119-A7A8-8954907B825C@justtesting.org> References: <4E06663C-C48C-4119-A7A8-8954907B825C@justtesting.org> Message-ID: <59e0088143004330b62b08919802a3ff@DB4PR30MB030.064d.mgd.msft.net> | There is currently an interesting discussion on Reddit on GHC compile times Crikey. That's a long and rather discouraging thread. (It comes as a bit of a surprise to me: I don't have much problem myself with GHC, which is by any standards a big project; but clearly others do.) I hate hearing people feeling so unhappy with GHC. And yet, and yet -- I don't feel able to just down-tools on everything else and work on perf. And that is true for many, I think. It's a tragedy-of-the-commons problem. What to do? Some thoughts. * GHC itself may or may not be the main culprit. There seems to be some muttering about Cabal. * We have had various attempts to appoint a Performance Tsar, but all have come to nothing. * We discussed it in our weekly GHC Skype chat yesterday. One thing that would really help is to make it laughably easy to track - Micro: whether my commit made anything significantly worse (compile time/allocs, run time/allocs, binary size) - Macro: how HEAD is doing relative to the previous release Our current tools are weak, and make it too hard. - We need a small number of aggregated numbers, not hundreds of numbers. (You might want the hundreds when digging into the details.) - We should include nofib, not just tests/perf - Our current perf tests only complain when you go outside a window, but 90% of the lossage might have been from other patches, which demotivates dealing with it - We don?t have any tools that show what time/alloc gets spent in which pass. * You would think that perf improvements would be something lots of people would like to work on: EVERYONE will love you. But in fact no one does. Increase incentives: maybe out tooling could generate a leader-board showing who is responsible for what total perf improvement, so that glory gets properly allocated. Paying for it. Austin found companies who are nearly at the point of hiring someone to work on perf. Maybe a collection of companies could together pay Well Typed for a GHC perf engineer, who focused on nothing else. That would be amazing. Any other ideas? Simon | -----Original Message----- | From: Manuel M T Chakravarty [mailto:chak at justtesting.org] | Sent: 14 February 2016 23:14 | To: GHC developers | Cc: Simon Peyton Jones ; Simon Marlow | | Subject: Fwd: Is anything being done to remedy the soul crushing compile | times of GHC? | | There is currently an interesting discussion on Reddit on GHC compile times | | | https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.reddit.c | om%2fr%2fhaskell%2fcomments%2f45q90s%2fis_anything_being_done_to_remedy_the_s | oul%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c01d58fefbba44e5cb27e | 08d33594990e%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Xqnm6BreVSdpGJgP9oA | L%2bMkC1QjRPYko%2f18iliKW8vk%3d | | I feel that this is a serious problem; so, it probably ought to be discussed | here as well. | | Manuel From eric at seidel.io Tue Feb 16 15:14:55 2016 From: eric at seidel.io (Eric Seidel) Date: Tue, 16 Feb 2016 07:14:55 -0800 Subject: Is anything being done to remedy the soul crushing compile times of GHC? In-Reply-To: <59e0088143004330b62b08919802a3ff@DB4PR30MB030.064d.mgd.msft.net> References: <4E06663C-C48C-4119-A7A8-8954907B825C@justtesting.org> <59e0088143004330b62b08919802a3ff@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <1455635695.2657592.522749994.1C28F588@webmail.messagingengine.com> On Tue, Feb 16, 2016, at 05:49, Simon Peyton Jones wrote: > * We discussed it in our weekly GHC Skype chat yesterday. One thing that > would really help is to make it laughably easy to track > - Micro: whether my commit made anything significantly worse > (compile time/allocs, run time/allocs, binary size) > - Our current perf tests only complain when you go outside > a window, but 90% of the lossage might have been from other > patches, which demotivates dealing with it It might be useful it phabricator ran the perf tests / nofib for every patch and displayed a warning (think a lint warning) if any of the metrics got worse. The warning would foster discussion about what caused the perf regression and whether it needs to be fixed *before* merging the patch. The current process for dealing with perf regressions seems to revolve around Joachim noticing that gipeda is reporting a regression, and raising a concern with the patch *after* it's been landed. This is entirely too late because the author will have moved on to something else, and to have to go back and work on a patch you thought was done is a bit demoralizing. To be clear, I'm very grateful for Joachim's work here, even when it involves flagging my patches :) But I think it would be better if we were *proactive* about the regressions rather than *reactive*. Eric From eir at cis.upenn.edu Tue Feb 16 15:28:04 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Tue, 16 Feb 2016 10:28:04 -0500 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: <8737st6iyg.fsf@smart-cactus.org> References: <87egcg93zn.fsf@smart-cactus.org> <1455381609.2134.16.camel@gmail.com> <87si0u6y9h.fsf@smart-cactus.org> <8737st6iyg.fsf@smart-cactus.org> Message-ID: <98EE8A62-8397-4D21-ABB4-63D4604D7062@cis.upenn.edu> On Feb 16, 2016, at 5:35 AM, Ben Gamari wrote: > Indeed. I'll just say that I envision that a beginner's prelude would be > for learning and nothing more. The goal is that it would be used in the > first dozen hours of picking up the language and nothing more. > > I'd be interested to hear what Richard had in mind when he has time > again. Yes, that's right. And, of course, it doesn't even need to be something released with GHC. I hope to have the opportunity to teach intro Haskell in the not-too-distant future. Maybe even this coming fall. Though I have yet to look closely at Chris's book, which will be one of the first things I do to prep, I suspect I'll be writing a custom Prelude for my first few weeks of the class, eliminating all type-classes. No Foldable, no Monoid, no Num. And then, by week 3 or 4, bring all that back in. Richard From ben at well-typed.com Tue Feb 16 15:28:56 2016 From: ben at well-typed.com (Ben Gamari) Date: Tue, 16 Feb 2016 16:28:56 +0100 Subject: Is anything being done to remedy the soul crushing compile times of GHC? In-Reply-To: <1455635695.2657592.522749994.1C28F588@webmail.messagingengine.com> References: <4E06663C-C48C-4119-A7A8-8954907B825C@justtesting.org> <59e0088143004330b62b08919802a3ff@DB4PR30MB030.064d.mgd.msft.net> <1455635695.2657592.522749994.1C28F588@webmail.messagingengine.com> Message-ID: <8737ss65dz.fsf@smart-cactus.org> Eric Seidel writes: > On Tue, Feb 16, 2016, at 05:49, Simon Peyton Jones wrote: >> * We discussed it in our weekly GHC Skype chat yesterday. One thing that >> would really help is to make it laughably easy to track >> - Micro: whether my commit made anything significantly worse >> (compile time/allocs, run time/allocs, binary size) >> - Our current perf tests only complain when you go outside >> a window, but 90% of the lossage might have been from other >> patches, which demotivates dealing with it > > It might be useful it phabricator ran the perf tests / nofib for every > patch and displayed a warning (think a lint warning) if any of the > metrics got worse. The warning would foster discussion about what caused > the perf regression and whether it needs to be fixed *before* merging > the patch. > Indeed we do already run the performance tests but at the moment you only get a thumbs-up or thumbs-down. One of my tasks for this week is to try adding better reporting of compiler performance in the testsuite driver. 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 Feb 16 15:41:21 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 16 Feb 2016 16:41:21 +0100 Subject: Fwd: Is anything being done to remedy the soul crushing compile times of GHC? In-Reply-To: <4E06663C-C48C-4119-A7A8-8954907B825C@justtesting.org> References: <4E06663C-C48C-4119-A7A8-8954907B825C@justtesting.org> Message-ID: <87y4ak4q8u.fsf@smart-cactus.org> Manuel M T Chakravarty writes: > There is currently an interesting discussion on Reddit on GHC compile > times > > https://www.reddit.com/r/haskell/comments/45q90s/is_anything_being_done_to_remedy_the_soul/ > > I feel that this is a serious problem; so, it probably ought to be > discussed here as well. One area that is in terrible need of attention is nofib itself. It's a good start but it needs many more testcases representative of today's idiomatic Haskell. It would be great if we could get users to submit their computationally-heavy, toy projects. Unfortunately, the best testcases for us are those with no dependencies outside of the core libraries and these projects aren't terribly common. 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 _deepfire at feelingofgreen.ru Tue Feb 16 17:58:57 2016 From: _deepfire at feelingofgreen.ru (Kosyrev Serge) Date: Tue, 16 Feb 2016 20:58:57 +0300 Subject: Fwd: Is anything being done to remedy the soul crushing compile times of GHC? In-Reply-To: <87y4ak4q8u.fsf@smart-cactus.org> (sfid-20160216_190730_365617_642EE00E) (Ben Gamari's message of "Tue, 16 Feb 2016 16:41:21 +0100") References: <4E06663C-C48C-4119-A7A8-8954907B825C@justtesting.org> <87y4ak4q8u.fsf@smart-cactus.org> Message-ID: <87io1oiljy.fsf@feelingofgreen.ru> Ben Gamari writes: > It would be great if we could get users to submit their > computationally-heavy, toy projects. Unfortunately, the best testcases > for us are those with no dependencies outside of the core libraries and > these projects aren't terribly common. This appears extremely unfortunate, because it is *the* metric that is really representative of end user experience. There is a number of factors that affect speed of the builds, and one could imagine how the profiles for the entirety of build process can vary due to the amount of cross-module dependencies, for example. -- ? ???????e? / respectfully, ??????? ?????? From ben at smart-cactus.org Tue Feb 16 19:38:16 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 16 Feb 2016 20:38:16 +0100 Subject: Fwd: Is anything being done to remedy the soul crushing compile times of GHC? In-Reply-To: <87io1oiljy.fsf@feelingofgreen.ru> References: <4E06663C-C48C-4119-A7A8-8954907B825C@justtesting.org> <87y4ak4q8u.fsf@smart-cactus.org> <87io1oiljy.fsf@feelingofgreen.ru> Message-ID: <87mvr04f9z.fsf@smart-cactus.org> Kosyrev Serge <_deepfire at feelingofgreen.ru> writes: > Ben Gamari writes: >> It would be great if we could get users to submit their >> computationally-heavy, toy projects. Unfortunately, the best testcases >> for us are those with no dependencies outside of the core libraries and >> these projects aren't terribly common. > > This appears extremely unfortunate, because it is *the* metric that is > really representative of end user experience. > Multiple modules aren't a problem. It is dependencies on Hackage packages that complicate matters. 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 chak at justtesting.org Tue Feb 16 23:05:47 2016 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Wed, 17 Feb 2016 10:05:47 +1100 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: <98EE8A62-8397-4D21-ABB4-63D4604D7062@cis.upenn.edu> References: <87egcg93zn.fsf@smart-cactus.org> <1455381609.2134.16.camel@gmail.com> <87si0u6y9h.fsf@smart-cactus.org> <8737st6iyg.fsf@smart-cactus.org> <98EE8A62-8397-4D21-ABB4-63D4604D7062@cis.upenn.edu> Message-ID: <9723F5A2-8FA7-4389-AE55-B46481748216@justtesting.org> > Richard Eisenberg : > > On Feb 16, 2016, at 5:35 AM, Ben Gamari wrote: >> Indeed. I'll just say that I envision that a beginner's prelude would be >> for learning and nothing more. The goal is that it would be used in the >> first dozen hours of picking up the language and nothing more. >> >> I'd be interested to hear what Richard had in mind when he has time >> again. > > Yes, that's right. And, of course, it doesn't even need to be something released with GHC. > > I hope to have the opportunity to teach intro Haskell in the not-too-distant future. Maybe even this coming fall. Though I have yet to look closely at Chris's book, which will be one of the first things I do to prep, I suspect I'll be writing a custom Prelude for my first few weeks of the class, eliminating all type-classes. No Foldable, no Monoid, no Num. And then, by week 3 or 4, bring all that back in. As somebody who has taught Haskell to hordes of students (literally, 1000s), I am not at all convinced that this is going to be helpful. This is for the following reasons: * Students understand the basic idea of overloading for Num, Show, etc easily (week 1 or 2). We actually tried both doing basic overloading very early or delaying it until later. The former worked much better. * You are not in a position to explain Foldable and probably not Monoid by week 3 or 4. So, either you need to have more than one beginner Prelude, delay overloading until much later (awkward), or we are really only talking about the impact of Show, Num, etc here. * Changing things (i.e., one Prelude to another) always confuses some people ? i.e., there is an intellectual cost to all this. * Students will want to use Haskell on their own computers. Then, you need to make sure, they import the right Prelude and that they stop importing the beginner Prelude when you switch back to the normal one. A certain percentage of students will mess that up and be confused. What we found works best is the following: * Introduce the concept of overloading right away. People get that easily, because they use overloaded arithmetic functions in math, too. (Num and Show are the typical classes to explain it at.) As an example, see how we do that in the first chapter of our new Haskell tutorial: http://learn.hfm.io/first_steps.html * Be careful in designing your exercises/assignments (esp early ones), to make it unlikely for students to run into class related errors. Sorry for the mostly off-topic post, but since a beginner?s Prelude was mentioned here multiple times recently as a countermeasure to making the real Prelude more complicated, I just want to say, don?t put too much hope into a ?solution? you never actually tried. Manuel From george.colpitts at gmail.com Wed Feb 17 00:39:53 2016 From: george.colpitts at gmail.com (George Colpitts) Date: Wed, 17 Feb 2016 00:39:53 +0000 Subject: Installing Cabal for GHC 8.0 release candidates In-Reply-To: <87mvr06a7x.fsf@smart-cactus.org> References: <87mvr06a7x.fsf@smart-cactus.org> Message-ID: works for me, on my Mac On Tue, Feb 16, 2016 at 9:44 AM Ben Gamari wrote: > > Hello everyone, > > Our wonderful Cabal release manager Mikhail Glushenkov has kindly > uploaded candidate releases of Cabal and cabal-install for use by GHC > 8.0 release candidate users. Now updating to a GHC 8.0-compatible > Cabal/cabal-install should be as simple as, > > cabal install \ > > http://hackage.haskell.org/package/Cabal-1.23.1.0/candidate/Cabal-1.23.1.0.tar.gz > \ > > http://hackage.haskell.org/package/cabal-install-1.23.0.0/candidate/cabal-install-1.23.0.0.tar.gz > > Happy testing! > > Cheers, > > - Ben > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmct at jmct.cc Wed Feb 17 04:50:25 2016 From: jmct at jmct.cc (=?UTF-8?Q?Jos=C3=A9_Manuel_Calder=C3=B3n_Trilla?=) Date: Tue, 16 Feb 2016 23:50:25 -0500 Subject: Generalising the demand analysis to sum types Message-ID: Hello ghc-devs, Apologies for the longish email. I'm looking to generalise GHC's demand analysis to work on sum types. This is in connection with the work on unboxed sums. The idea is that if the strictness analysis tells us that a sum type is strict in all the fields of all of its constructors, it is safe to unbox that sum automatically. We hope for this to feed into a worker/wrapper like transformation for sum types. I am new to the GHC codebase and wanted to make sure that my plan of attack seemed sensible to you all. GHC's current type representing demand is StrDmd, which is defined as follows: data StrDmd = HyperStrict | SCall StrDmd | SProd [ArgStr] | HeadStr I believe that adding sum types will be as simple as adding a single new constructor for Sums: data StrDmd = HyperStrict | SCall StrDmd | SProd [ArgStr] | SSum [(Tag, StrDmd)] | HeadStr We need the constructor tag so that we can analyze each branch of a case expression independently before combining the results of each branch. Since we only care if all fields are strict for all constructors, we won't actually use the tag information except in the analysis itself. Projection-based strictness analysis on sum types is not new (though sum types + higher-order seems to be). That being said, all previous treatments of the subject that I'm aware of forbid polymorphic recursion. Luckily for us we aren't trying to unbox recursive types, so for now [1] we will not attempt to analyze recursive types, hence no SMu or SRec constructor above. With the analysis accepting sum types we will be able to analyze functions with sum types as parameters, as a trivial example: fromMaybe2 x y = case x of Just v -> v Nothing -> y You would get a demand signature like: Str=Dmdtype ), ("Nothing", <>)],U> Which says that the function is strict in its first argument and that if the value is a 'Just' then its field is used strictly, if the value is a 'Nothing' then there is no further demand (a nullary product). For those with more experience in these matter, does this seem to be a sensible approach? Thanks in advance for any insight, Jose [1]: Those of you who saw my Haskell Symposium talk on implicit parallelism last year might remember that we will need the analysis to work on recursive types in order to automatically generate parallel strategies, but that's for later (I've spoken with Ilya Sergey about working on that). From qdunkan at gmail.com Wed Feb 17 06:40:19 2016 From: qdunkan at gmail.com (Evan Laforge) Date: Wed, 17 Feb 2016 15:40:19 +0900 Subject: Fwd: Is anything being done to remedy the soul crushing compile times of GHC? In-Reply-To: <87mvr04f9z.fsf@smart-cactus.org> References: <4E06663C-C48C-4119-A7A8-8954907B825C@justtesting.org> <87y4ak4q8u.fsf@smart-cactus.org> <87io1oiljy.fsf@feelingofgreen.ru> <87mvr04f9z.fsf@smart-cactus.org> Message-ID: On Wed, Feb 17, 2016 at 4:38 AM, Ben Gamari wrote: > Multiple modules aren't a problem. It is dependencies on Hackage > packages that complicate matters. I guess the problem is when ghc breaks a bunch of hackage packages, you can't build with it anymore until those packages are updated, which won't happen until after the release? >From a certain point of view, this could be motivation to either break fewer things, or to patch breaking dependents as soon as the breaking patch goes into ghc. Which doesn't sound so bad in theory. Of course someone would need to spend time doing boring maintenance, but it seems that will be required regardless. And ultimately someone has to do it eventually. Of course, said person's boring time might be better spent directly addressing known performance problems. My impression from the reddit thread is that three things are going on: 1 - cabal has quite a bit of startup overhead 2 - ghc takes a long time on certain inputs, e.g. long list literals. There are probably already tickets for these. 3 - and of course, ghc can be just generally slow, in the million tiny cuts sense. I personally haven't run into these (though I don't doubt those who have), so don't get too discouraged! From mail at joachim-breitner.de Wed Feb 17 08:15:27 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 17 Feb 2016 09:15:27 +0100 Subject: Generalising the demand analysis to sum types In-Reply-To: References: Message-ID: <1455696927.1579.9.camel@joachim-breitner.de> Hi, interesting! Am Dienstag, den 16.02.2016, 23:50 -0500 schrieb Jos? Manuel Calder?n Trilla: > For those with more experience in these matter, does this seem to be > a sensible approach? not sure if I qualify, but I have two questions nevertheless.? You write "fromMaybe2", but (besides the order of the argument) it is the same as the library "fromMaybe". Is the order of the arguments relevant? And more importatly: Can you outline what you want to do with the result of the analysis? A worker-wrapper transformation of "fromMaybe" with a worker that takes an unboxed sum type? If so, what would be the unboxed sum type be here? (With products it is easier, because you can just pass the components as arguments, or use unboxed tuples. But here you would need more complicated unboxed types.) BTW, what is the status of https://ghc.haskell.org/trac/ghc/wiki/UnpackedSumTypes?? Greetings, Joachim -- Joachim ?nomeata? Breitner ? mail at joachim-breitner.de ? https://www.joachim-breitner.de/ ? XMPP: nomeata at joachim-breitner.de?? OpenPGP-Key: 0xF0FBF51F ? Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Wed Feb 17 08:22:27 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 17 Feb 2016 09:22:27 +0100 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: <9723F5A2-8FA7-4389-AE55-B46481748216@justtesting.org> References: <87egcg93zn.fsf@smart-cactus.org> <1455381609.2134.16.camel@gmail.com> <87si0u6y9h.fsf@smart-cactus.org> <8737st6iyg.fsf@smart-cactus.org> <98EE8A62-8397-4D21-ABB4-63D4604D7062@cis.upenn.edu> <9723F5A2-8FA7-4389-AE55-B46481748216@justtesting.org> Message-ID: <1455697347.1579.14.camel@joachim-breitner.de> Hi, Am Mittwoch, den 17.02.2016, 10:05 +1100 schrieb Manuel M T Chakravarty: > * Be careful in designing your exercises/assignments (esp early > ones), to make it unlikely for students to run into class related > errors. have you, or someone else, considered or tried to simply have students start with their own list data type, i.e. data List a = Nil | Cons a (List a) and have them implement the combinators they need themselves? Of course, you?d have to tell them to use names that do not clash with Prelude-exported, but this would avoid Foldable et. al. and be more educational (at the expense of maybe a slower progress, and not having nice syntax). Similarly, one could teach them about the non-magicness of $ and side- step the issue with $ by having them write? ($$) ? :: (a -> b) -> a -> b f $$ x =??f x infixr 0??$ (or whatever symbol they fancy). This would be akin to using a beginner?s prelude, only that the students would be writing it themselves, which IMHO is a big difference from an educational point of view. Greetings, Joachim -- Joachim ?nomeata? Breitner ? mail at joachim-breitner.de ? https://www.joachim-breitner.de/ ? XMPP: nomeata at joachim-breitner.de?? OpenPGP-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 Wed Feb 17 08:58:43 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 17 Feb 2016 09:58:43 +0100 Subject: Fwd: Is anything being done to remedy the soul crushing compile times of GHC? In-Reply-To: References: <4E06663C-C48C-4119-A7A8-8954907B825C@justtesting.org> <87y4ak4q8u.fsf@smart-cactus.org> <87io1oiljy.fsf@feelingofgreen.ru> <87mvr04f9z.fsf@smart-cactus.org> Message-ID: <87egcb4ssc.fsf@smart-cactus.org> Evan Laforge writes: > On Wed, Feb 17, 2016 at 4:38 AM, Ben Gamari wrote: >> Multiple modules aren't a problem. It is dependencies on Hackage >> packages that complicate matters. > > I guess the problem is when ghc breaks a bunch of hackage packages, > you can't build with it anymore until those packages are updated, > which won't happen until after the release? > This is one issue, although perhaps not the largest. Here are some of the issues I can think of off the top of my head, * The issue you point out: Hackage packages need to be updated * Hackage dependencies mean that the performance of the testcase is now dependent upon code over which we have no control. If a test's performance improves is this because the compiler improved or merely because a dependency of the testcase was optimized? Of course, you could maintain a stable fork of the dependency, but at this point you might as well just take the pieces you need and fold them into the testcase. * Hackage dependencies greatly complicate packaging. You need to somehow download and install them. The obvious approach here is to use cabal-install but it is unavailable during a GHC build * Hackage dependencies make it much harder to determine what the compiler is doing. If I have a directory of modules, I can rebuild all of them with `ghc --make -fforce-recomp`. Things are quite a bit trickier when packages enter the picture. In short, the whole packaging system really acts as nothing more than a confounding factor for performance analysis, in addition to making implementation quite a bit trickier. That being said, developing another performance testsuite consisting of a set of larger, dependency-ful applications may be useful at some point. I think the first priority, however, should be nofib. > From a certain point of view, this could be motivation to either break > fewer things, or to patch breaking dependents as soon as the breaking > patch goes into ghc. Which doesn't sound so bad in theory. Of course > someone would need to spend time doing boring maintenance, but it > seems that will be required regardless. And ultimately someone has to > do it eventually. > Much of the effort necessary to bring Hackage up to speed with a new GHC release isn't due to breakage; it's just bumping version bounds. I'm afraid the GHC project really doesn't have the man-power to do this work consistently. We already owe hvr a significant amount of gratitude for handling so many of these issues leading up to the release. > Of course, said person's boring time might be better spent directly > addressing known performance problems. > Indeed. > My impression from the reddit thread is that three things are going on: > > 1 - cabal has quite a bit of startup overhead Yes, it would be great if someone could step up to look at Cabal's performance. Running `cabal build` on an up-to-date tree of a moderately-sized (10 kLoC, 8 components, 60 modules) Haskell project I have laying around takes over 5 seconds from start-to-finish. `cabal build`ing just a single executable component takes 4 seconds. This same executable takes 48 seconds for GHC to build from scratch with optimization and 12 seconds without. > 2 - ghc takes a long time on certain inputs, e.g. long list literals. > There are probably already tickets for these. > Indeed, there are plenty of pathological cases. For better or worse, these are generally the "easier" performance problems to tackle. > 3 - and of course, ghc can be just generally slow, in the million tiny > cuts sense. > And this is the tricky one. Beginning to tackle this will require that someone perform some very careful measurements on current and previous releases. Performance issues are always on my and Austin's to-do list, but we are unfortunately rather limited in the amount of time we can spend on these due to funding considerations. As Simon mentioned, if someone would like to see this fixed and has money to put towards the cause, we would love to hear from you. 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 chak at justtesting.org Wed Feb 17 08:59:38 2016 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Wed, 17 Feb 2016 19:59:38 +1100 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: <1455697347.1579.14.camel@joachim-breitner.de> References: <87egcg93zn.fsf@smart-cactus.org> <1455381609.2134.16.camel@gmail.com> <87si0u6y9h.fsf@smart-cactus.org> <8737st6iyg.fsf@smart-cactus.org> <98EE8A62-8397-4D21-ABB4-63D4604D7062@cis.upenn.edu> <9723F5A2-8FA7-4389-AE55-B46481748216@justtesting.org> <1455697347.1579.14.camel@joachim-breitner.de> Message-ID: We have tried variations of this. This approach has two problems. (1) It?s generally easier to use something than to define it and, e.g., in the case of lists, Haskell ?magic? syntax is more intuitive to use. For example, we use lists for a while before we define them. Even recursive definitions with pattern matching on [] and (:) are fairly easy to explain and for students to write quite a while before we discuss data declarations. The build-in syntax for lists is convenient for using collections before properly explaining the full structure of terms and the concept of data constructors etc. (2) We repeatedly found that any for-teaching-only definitions come with quite a bit of hidden costs. At some point, you need to make the transition from the for-teaching-only definitions to the ?real? definitions. At this point, you invariably lose the students who managed to just get everything up to that point ? i.e., those students that were struggling anyway. For us, alpha renaming is a trivial process. However, learners (and esp. the weaker learners) are rather tied to syntax and concrete names. They don?t deal well with alpha renaming. Additionally, by introducing for-teaching-only definitions, you basically cut learners of from all the online resources that they could otherwise access. You probably won?t be able to match it up with a textbook unless you write one yourself. (Even if there is a book, this book then becomes the only resource.) This is an enormous disadvantage. Manuel > Joachim Breitner : > Am Mittwoch, den 17.02.2016, 10:05 +1100 schrieb Manuel M T Chakravarty: >> * Be careful in designing your exercises/assignments (esp early >> ones), to make it unlikely for students to run into class related >> errors. > > have you, or someone else, considered or tried to simply have students > start with their own list data type, i.e. > > data List a = Nil | Cons a (List a) > > and have them implement the combinators they need themselves? Of > course, you?d have to tell them to use names that do not clash with > Prelude-exported, but this would avoid Foldable et. al. and be more > educational (at the expense of maybe a slower progress, and not having > nice syntax). > > Similarly, one could teach them about the non-magicness of $ and side- > step the issue with $ by having them write > > ($$) :: (a -> b) -> a -> b > f $$ x = f x > infixr 0 $ > > (or whatever symbol they fancy). > > > This would be akin to using a beginner?s prelude, only that the > students would be writing it themselves, which IMHO is a big difference > from an educational point of view. > > > Greetings, > Joachim > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? https://www.joachim-breitner.de/ > XMPP: nomeata at joachim-breitner.de ? OpenPGP-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 Wed Feb 17 09:01:26 2016 From: ben at well-typed.com (Ben Gamari) Date: Wed, 17 Feb 2016 10:01:26 +0100 Subject: Installing Cabal for GHC 8.0 release candidates In-Reply-To: References: <87mvr06a7x.fsf@smart-cactus.org> Message-ID: <87bn7f4snt.fsf@smart-cactus.org> George Colpitts writes: > works for me, on my Mac > Thanks for the confirmation, George! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ezyang at mit.edu Wed Feb 17 10:14:00 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Wed, 17 Feb 2016 02:14:00 -0800 Subject: Fwd: Is anything being done to remedy the soul crushing compile times of GHC? In-Reply-To: <87egcb4ssc.fsf@smart-cactus.org> References: <4E06663C-C48C-4119-A7A8-8954907B825C@justtesting.org> <87y4ak4q8u.fsf@smart-cactus.org> <87io1oiljy.fsf@feelingofgreen.ru> <87mvr04f9z.fsf@smart-cactus.org> <87egcb4ssc.fsf@smart-cactus.org> Message-ID: <1455703870-sup-946@sabre> Another large culprit for performance is that the fact that ghc --make must preprocess and parse the header of every local Haskell file: https://ghc.haskell.org/trac/ghc/ticket/618 (as well as https://ghc.haskell.org/trac/ghc/ticket/1290). Neil and I have observed that when you use something better (like Shake) recompilation performance gets a lot better, esp. when you have a lot of modules. Edward Excerpts from Ben Gamari's message of 2016-02-17 00:58:43 -0800: > Evan Laforge writes: > > > On Wed, Feb 17, 2016 at 4:38 AM, Ben Gamari wrote: > >> Multiple modules aren't a problem. It is dependencies on Hackage > >> packages that complicate matters. > > > > I guess the problem is when ghc breaks a bunch of hackage packages, > > you can't build with it anymore until those packages are updated, > > which won't happen until after the release? > > > This is one issue, although perhaps not the largest. Here are some of > the issues I can think of off the top of my head, > > * The issue you point out: Hackage packages need to be updated > > * Hackage dependencies mean that the performance of the testcase is now > dependent upon code over which we have no control. If a test's > performance improves is this because the compiler improved or merely > because a dependency of the testcase was optimized? > > Of course, you could maintain a stable fork of the dependency, but > at this point you might as well just take the pieces you need and > fold them into the testcase. > > * Hackage dependencies greatly complicate packaging. You need to > somehow download and install them. The obvious approach here is to > use cabal-install but it is unavailable during a GHC build > > * Hackage dependencies make it much harder to determine what the > compiler is doing. If I have a directory of modules, I can rebuild > all of them with `ghc --make -fforce-recomp`. Things are quite a bit > trickier when packages enter the picture. > > In short, the whole packaging system really acts as nothing more than a > confounding factor for performance analysis, in addition to making > implementation quite a bit trickier. > > That being said, developing another performance testsuite consisting of > a set of larger, dependency-ful applications may be useful at some > point. I think the first priority, however, should be nofib. > > > From a certain point of view, this could be motivation to either break > > fewer things, or to patch breaking dependents as soon as the breaking > > patch goes into ghc. Which doesn't sound so bad in theory. Of course > > someone would need to spend time doing boring maintenance, but it > > seems that will be required regardless. And ultimately someone has to > > do it eventually. > > > Much of the effort necessary to bring Hackage up to speed with a new GHC > release isn't due to breakage; it's just bumping version bounds. I'm > afraid the GHC project really doesn't have the man-power to do this work > consistently. We already owe hvr a significant amount of gratitude for > handling so many of these issues leading up to the release. > > > Of course, said person's boring time might be better spent directly > > addressing known performance problems. > > > Indeed. > > > My impression from the reddit thread is that three things are going on: > > > > 1 - cabal has quite a bit of startup overhead > > Yes, it would be great if someone could step up to look at Cabal's > performance. Running `cabal build` on an up-to-date tree of a > moderately-sized (10 kLoC, 8 components, 60 modules) Haskell project I > have laying around takes over 5 seconds from start-to-finish. > > `cabal build`ing just a single executable component takes 4 seconds. > This same executable takes 48 seconds for GHC to build from scratch with > optimization and 12 seconds without. > > > 2 - ghc takes a long time on certain inputs, e.g. long list literals. > > There are probably already tickets for these. > > > Indeed, there are plenty of pathological cases. For better or worse, > these are generally the "easier" performance problems to tackle. > > > 3 - and of course, ghc can be just generally slow, in the million tiny > > cuts sense. > > > And this is the tricky one. Beginning to tackle this will require that > someone perform some very careful measurements on current and previous > releases. > > Performance issues are always on my and Austin's to-do list, but we are > unfortunately rather limited in the amount of time we can spend on these > due to funding considerations. As Simon mentioned, if someone would like > to see this fixed and has money to put towards the cause, we would love > to hear from you. > > Cheers, > > - Ben From takenobu.hs at gmail.com Wed Feb 17 13:09:59 2016 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Wed, 17 Feb 2016 22:09:59 +0900 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: References: <0210F72D-CCF3-452A-BAD4-15796F288FD9@justtesting.org> <1454628457-sup-7751@sabre> <56B44DCE.5010602@ro-che.info> <1454663966.1570.1.camel@joachim-breitner.de> Message-ID: Hi Alexander, > Prelude> :t foldr > foldr :: Foldable t => (a -> b -> b) -> b -> t a -> b > For example: > foldr :: (a -> b -> b) -> b -> [a] -> b > foldr :: (a -> b -> b) -> b -> Maybe a -> b > foldr :: (a -> b -> b) -> b -> Identity a -> b > foldr :: (a -> b -> b) -> b -> (c, a) -> b > and more > > It is easy to see a pattern here. The order of the instances used could be the load order, so the ones from Prelude would come first. interesting idea. It's ":t" 's verbose representation mode. The ghci represents true type (not lie) and beginners may intuitively understand the relation between Foldable type class and instances. Beginners will be overcome FTP more easily. > Prelude> :t ($) > ($) :: <"unreadable blurb"> > For example: > ($) :: (a -> b) -> a -> b > ($) :: forall a (b :: #). (a -> b) -> a -> b > > At least one of those lines should be understandable. It's one of the options. But I feel that Levity (or RuntimeRep) is more deep than the type class. They may feel difficult to understand the difference of two patterns in ($). (If it will be long, it's better to separate thread =) ) Regards, Takenobu 2016-02-16 16:28 GMT+09:00 Alexander Kjeldaas : > > > On Fri, Feb 5, 2016 at 2:16 PM, Takenobu Tani > wrote: > >> Hi, >> >> I'll worry about the learning curve of beginners. >> Maybe, beginners will try following session in their 1st week. >> >> ghci> :t foldr >> ghci> :t ($) >> >> They'll get following result. >> >> >> Before ghc7.8: >> >> Prelude> :t foldr >> foldr :: (a -> b -> b) -> b -> [a] -> b >> >> Prelude> :t ($) >> ($) :: (a -> b) -> a -> b >> >> Beginners should only understand about following: >> >> * type variable (polymorphism) >> >> >> After ghc8.0: >> >> Prelude> :t foldr >> foldr :: Foldable t => (a -> b -> b) -> b -> t a -> b >> >> > If the output was the following it would be more understandable (and more > encouraging!) > > """ > Prelude> :t foldr > foldr :: Foldable t => (a -> b -> b) -> b -> t a -> b > For example: > foldr :: (a -> b -> b) -> b -> [a] -> b > foldr :: (a -> b -> b) -> b -> Maybe a -> b > foldr :: (a -> b -> b) -> b -> Identity a -> b > foldr :: (a -> b -> b) -> b -> (c, a) -> b > and more > """ > > It is easy to see a pattern here. The order of the instances used could > be the load order, so the ones from Prelude would come first. > > > >> Prelude> :t ($) >> ($) >> :: forall (w :: GHC.Types.Levity) a (b :: TYPE w). >> (a -> b) -> a -> b >> >> > I'm not sure how this would work here, but when Levity is *, this should > collapse into the old syntax, so: > > """ > Prelude> :t ($) > ($) :: <"unreadable blurb"> > For example: > ($) :: (a -> b) -> a -> b > ($) :: forall a (b :: #). (a -> b) -> a -> b > """ > > At least one of those lines should be understandable. > > Alexander > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From takenobu.hs at gmail.com Wed Feb 17 13:18:56 2016 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Wed, 17 Feb 2016 22:18:56 +0900 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: <9723F5A2-8FA7-4389-AE55-B46481748216@justtesting.org> References: <87egcg93zn.fsf@smart-cactus.org> <1455381609.2134.16.camel@gmail.com> <87si0u6y9h.fsf@smart-cactus.org> <8737st6iyg.fsf@smart-cactus.org> <98EE8A62-8397-4D21-ABB4-63D4604D7062@cis.upenn.edu> <9723F5A2-8FA7-4389-AE55-B46481748216@justtesting.org> Message-ID: Hi Manuel, > * Introduce the concept of overloading right away. People get that easily, > because they use overloaded arithmetic functions in math, too. > (Num and Show are the typical classes to explain it at.) > As an example, see how we do that in the first chapter of our new Haskell > tutorial: http://learn.hfm.io/first_steps.html This is straightforward and elegance tutorial! I like this. As you know, I'll share one point to list. It's better to assume that "beginners are not only students in universities". Beginners are also engineers, hobbyist, teenager, your friends and your family. Someone of them will touch to Haskell alone and learn with self study in a little bit of knowledge. If they feel complex at first impression in their 1st week, they would go back before they realize beauty of Haskell. Sometimes, I'm worried about it. Regards, Takenobu 2016-02-17 8:05 GMT+09:00 Manuel M T Chakravarty : > > Richard Eisenberg : > > > > On Feb 16, 2016, at 5:35 AM, Ben Gamari wrote: > >> Indeed. I'll just say that I envision that a beginner's prelude would be > >> for learning and nothing more. The goal is that it would be used in the > >> first dozen hours of picking up the language and nothing more. > >> > >> I'd be interested to hear what Richard had in mind when he has time > >> again. > > > > Yes, that's right. And, of course, it doesn't even need to be something > released with GHC. > > > > I hope to have the opportunity to teach intro Haskell in the > not-too-distant future. Maybe even this coming fall. Though I have yet to > look closely at Chris's book, which will be one of the first things I do to > prep, I suspect I'll be writing a custom Prelude for my first few weeks of > the class, eliminating all type-classes. No Foldable, no Monoid, no Num. > And then, by week 3 or 4, bring all that back in. > > As somebody who has taught Haskell to hordes of students (literally, > 1000s), I am not at all convinced that this is going to be helpful. This is > for the following reasons: > > * Students understand the basic idea of overloading for Num, Show, etc > easily (week 1 or 2). We actually tried both doing basic overloading very > early or delaying it until later. The former worked much better. > > * You are not in a position to explain Foldable and probably not Monoid by > week 3 or 4. So, either you need to have more than one beginner Prelude, > delay overloading until much later (awkward), or we are really only talking > about the impact of Show, Num, etc here. > > * Changing things (i.e., one Prelude to another) always confuses some > people ? i.e., there is an intellectual cost to all this. > > * Students will want to use Haskell on their own computers. Then, you need > to make sure, they import the right Prelude and that they stop importing > the beginner Prelude when you switch back to the normal one. A certain > percentage of students will mess that up and be confused. > > What we found works best is the following: > > * Introduce the concept of overloading right away. People get that easily, > because they use overloaded arithmetic functions in math, too. (Num and > Show are the typical classes to explain it at.) As an example, see how we > do that in the first chapter of our new Haskell tutorial: > http://learn.hfm.io/first_steps.html > > * Be careful in designing your exercises/assignments (esp early ones), to > make it unlikely for students to run into class related errors. > > Sorry for the mostly off-topic post, but since a beginner?s Prelude was > mentioned here multiple times recently as a countermeasure to making the > real Prelude more complicated, I just want to say, don?t put too much hope > into a ?solution? you never actually tried. > > Manuel > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuncer.ayaz at gmail.com Wed Feb 17 13:31:39 2016 From: tuncer.ayaz at gmail.com (Tuncer Ayaz) Date: Wed, 17 Feb 2016 14:31:39 +0100 Subject: Fwd: Is anything being done to remedy the soul crushing compile times of GHC? In-Reply-To: References: <4E06663C-C48C-4119-A7A8-8954907B825C@justtesting.org> <87y4ak4q8u.fsf@smart-cactus.org> <87io1oiljy.fsf@feelingofgreen.ru> <87mvr04f9z.fsf@smart-cactus.org> Message-ID: On 17 February 2016 at 07:40, Evan Laforge wrote: > My impression from the reddit thread is that three things are going > on: > > 1 - cabal has quite a bit of startup overhead > 2 - ghc takes a long time on certain inputs, e.g. long list literals. > There are probably already tickets for these. In my experience GHC startup overhead (time) has increased quite a lot somewhere in 7.x. I don't know if it's the cause, but perhaps dyn libs may be part of the reason. I'm not sure because I once (7.8 I believe) tried to build without dynlink support and couldn't measure a substantial improvement. So, if you start ghc(i) for the first time from a spinning disk, it's very noticeable and quite a delay. Once it's cached, it's fast, so I think it's primarily due to reading stuff from disk. Just to mention the ideal overhead: anything below 400ms is small enough to not disrupt the flow and feels responsive. Go over 1s and it breaks. From tuncer.ayaz at gmail.com Wed Feb 17 13:35:40 2016 From: tuncer.ayaz at gmail.com (Tuncer Ayaz) Date: Wed, 17 Feb 2016 14:35:40 +0100 Subject: Fwd: Is anything being done to remedy the soul crushing compile times of GHC? In-Reply-To: References: <4E06663C-C48C-4119-A7A8-8954907B825C@justtesting.org> <87y4ak4q8u.fsf@smart-cactus.org> <87io1oiljy.fsf@feelingofgreen.ru> <87mvr04f9z.fsf@smart-cactus.org> Message-ID: Here's a thought: has anyone experience with limiting a certain major release to just bug fixes and perf regression fixes, while postponing all feature patches? It sounds like a good idea on paper, but has anyone seen it work, and would this be something to consider for GHC? I'm not suggesting the even/odd versioning scheme, if anyone wonders. These don't work so well and nobody tests odd versions. From omeragacan at gmail.com Wed Feb 17 13:41:19 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Wed, 17 Feb 2016 08:41:19 -0500 Subject: Generalising the demand analysis to sum types In-Reply-To: <1455696927.1579.9.camel@joachim-breitner.de> References: <1455696927.1579.9.camel@joachim-breitner.de> Message-ID: 2016-02-17 3:15 GMT-05:00 Joachim Breitner : > BTW, what is the status of > https://ghc.haskell.org/trac/ghc/wiki/UnpackedSumTypes ? It's mostly done, you can try it here: https://github.com/osa1/ghc/tree/unboxed-sums-stg From simonpj at microsoft.com Wed Feb 17 14:09:24 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 17 Feb 2016 14:09:24 +0000 Subject: Generalising the demand analysis to sum types In-Reply-To: References: Message-ID: <5ef58ac4619940608835ec3662591316@DB4PR30MB030.064d.mgd.msft.net> I think you could do that. The key question is (as someone asked) what use you would make of the information. That is, what's the payoff? Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Jos? | Manuel Calder?n Trilla | Sent: 17 February 2016 04:50 | To: ghc-devs at haskell.org | Subject: Generalising the demand analysis to sum types | | Hello ghc-devs, | | Apologies for the longish email. | | I'm looking to generalise GHC's demand analysis to work on sum types. | This is in connection with the work on unboxed sums. The idea is that | if the strictness analysis tells us that a sum type is strict in all | the fields of all of its constructors, it is safe to unbox that sum | automatically. We hope for this to feed into a worker/wrapper like | transformation for sum types. | | I am new to the GHC codebase and wanted to make sure that my plan of | attack seemed sensible to you all. | | GHC's current type representing demand is StrDmd, which is defined as | follows: | | data StrDmd | = HyperStrict | | SCall StrDmd | | SProd [ArgStr] | | HeadStr | | I believe that adding sum types will be as simple as adding a single | new constructor for Sums: | | data StrDmd | = HyperStrict | | SCall StrDmd | | SProd [ArgStr] | | SSum [(Tag, StrDmd)] | | HeadStr | | We need the constructor tag so that we can analyze each branch of a | case expression independently before combining the results of each | branch. Since we only care if all fields are strict for all | constructors, we won't actually use the tag information except in the | analysis itself. | | Projection-based strictness analysis on sum types is not new (though | sum types + higher-order seems to be). That being said, all previous | treatments of the subject that I'm aware of forbid polymorphic | recursion. Luckily for us we aren't trying to unbox recursive types, so | for now [1] we will not attempt to analyze recursive types, hence no | SMu or SRec constructor above. | | With the analysis accepting sum types we will be able to analyze | functions with sum types as parameters, as a trivial example: | | fromMaybe2 x y = case x of | Just v -> v | Nothing -> y | | You would get a demand signature like: | | Str=Dmdtype ), ("Nothing", <>)],U> | | Which says that the function is strict in its first argument and that | if the value is a 'Just' then its field is used strictly, if the value | is a 'Nothing' then there is no further demand (a nullary product). | | For those with more experience in these matter, does this seem to be a | sensible approach? | | Thanks in advance for any insight, | | Jose | | | [1]: Those of you who saw my Haskell Symposium talk on implicit | parallelism last year might remember that we will need the analysis to | work on recursive types in order to automatically generate parallel | strategies, but that's for later (I've spoken with Ilya Sergey about | working on that). | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha | skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cf731333e0c5d45f3 | 298408d33755dc98%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=hWHFSUVrr | ZQqTPeQsFMQVlveHgV5ozx6%2bdpsylRIwhg%3d From austin at well-typed.com Wed Feb 17 14:47:27 2016 From: austin at well-typed.com (Austin Seipp) Date: Wed, 17 Feb 2016 08:47:27 -0600 Subject: Fwd: Is anything being done to remedy the soul crushing compile times of GHC? In-Reply-To: References: <4E06663C-C48C-4119-A7A8-8954907B825C@justtesting.org> <87y4ak4q8u.fsf@smart-cactus.org> <87io1oiljy.fsf@feelingofgreen.ru> <87mvr04f9z.fsf@smart-cactus.org> Message-ID: The better approach, I think, might be to section off certain times in a release period where we only allow such changes. Only for a month or so, for example, and you're just encouraged to park your current work for a little while, during that time, and just improve things. The only problem is, it's not clear if people will want to commit as much if the hard rule is just to fix bugs/improve performance for a select time. Nobody is obligated to contribute, so it could easily fall into a lull period if people get tired of it. But maybe the shared sense of community in doing it would help. Whatever we do, it has to be strict in these times, because in practice we have a policy like this ("just bug/perf fixes") during the time leading up to the RC, but we always slip and merge other things regardless. So, if we do this, we must be quite strict about it in practice and police ourselves better, I think. On Wed, Feb 17, 2016 at 7:35 AM, Tuncer Ayaz wrote: > Here's a thought: has anyone experience with limiting a certain major > release to just bug fixes and perf regression fixes, while postponing > all feature patches? It sounds like a good idea on paper, but has > anyone seen it work, and would this be something to consider for GHC? > I'm not suggesting the even/odd versioning scheme, if anyone wonders. > These don't work so well and nobody tests odd versions. > _______________________________________________ > 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 Feb 17 16:09:17 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Wed, 17 Feb 2016 10:09:17 -0600 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: <9723F5A2-8FA7-4389-AE55-B46481748216@justtesting.org> References: <87egcg93zn.fsf@smart-cactus.org> <1455381609.2134.16.camel@gmail.com> <87si0u6y9h.fsf@smart-cactus.org> <8737st6iyg.fsf@smart-cactus.org> <98EE8A62-8397-4D21-ABB4-63D4604D7062@cis.upenn.edu> <9723F5A2-8FA7-4389-AE55-B46481748216@justtesting.org> Message-ID: I agree 100% with Manuel here. My N is smaller (100s rather than thousands) but this is what I've seen working with self-learners, programmers and non-programmers alike. I don't have anything further to add because I couldn't find a point in his listing that didn't match my experience. > Sorry for the mostly off-topic post, but since a beginner?s Prelude was mentioned here multiple times recently as a countermeasure to making the real Prelude more complicated, I just want to say, don?t put too much hope into a ?solution? you never actually tried. I have tried a beginner's Prelude with people. I don't have a lot of data because it was clearly a failure early on so I bailed them out into the usual thing. It's just not worth it and it deprives them of the preparedness to go write real Haskell code. That's not something I'm willing to give up just so I can teach _less_. On Tue, Feb 16, 2016 at 5:05 PM, Manuel M T Chakravarty < chak at justtesting.org> wrote: > > Richard Eisenberg : > > > > On Feb 16, 2016, at 5:35 AM, Ben Gamari wrote: > >> Indeed. I'll just say that I envision that a beginner's prelude would be > >> for learning and nothing more. The goal is that it would be used in the > >> first dozen hours of picking up the language and nothing more. > >> > >> I'd be interested to hear what Richard had in mind when he has time > >> again. > > > > Yes, that's right. And, of course, it doesn't even need to be something > released with GHC. > > > > I hope to have the opportunity to teach intro Haskell in the > not-too-distant future. Maybe even this coming fall. Though I have yet to > look closely at Chris's book, which will be one of the first things I do to > prep, I suspect I'll be writing a custom Prelude for my first few weeks of > the class, eliminating all type-classes. No Foldable, no Monoid, no Num. > And then, by week 3 or 4, bring all that back in. > > As somebody who has taught Haskell to hordes of students (literally, > 1000s), I am not at all convinced that this is going to be helpful. This is > for the following reasons: > > * Students understand the basic idea of overloading for Num, Show, etc > easily (week 1 or 2). We actually tried both doing basic overloading very > early or delaying it until later. The former worked much better. > > * You are not in a position to explain Foldable and probably not Monoid by > week 3 or 4. So, either you need to have more than one beginner Prelude, > delay overloading until much later (awkward), or we are really only talking > about the impact of Show, Num, etc here. > > * Changing things (i.e., one Prelude to another) always confuses some > people ? i.e., there is an intellectual cost to all this. > > * Students will want to use Haskell on their own computers. Then, you need > to make sure, they import the right Prelude and that they stop importing > the beginner Prelude when you switch back to the normal one. A certain > percentage of students will mess that up and be confused. > > What we found works best is the following: > > * Introduce the concept of overloading right away. People get that easily, > because they use overloaded arithmetic functions in math, too. (Num and > Show are the typical classes to explain it at.) As an example, see how we > do that in the first chapter of our new Haskell tutorial: > http://learn.hfm.io/first_steps.html > > * Be careful in designing your exercises/assignments (esp early ones), to > make it unlikely for students to run into class related errors. > > Sorry for the mostly off-topic post, but since a beginner?s Prelude was > mentioned here multiple times recently as a countermeasure to making the > real Prelude more complicated, I just want to say, don?t put too much hope > into a ?solution? you never actually tried. > > Manuel > > _______________________________________________ > 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 ben at smart-cactus.org Wed Feb 17 20:00:38 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 17 Feb 2016 21:00:38 +0100 Subject: Fwd: Is anything being done to remedy the soul crushing compile times of GHC? In-Reply-To: References: <4E06663C-C48C-4119-A7A8-8954907B825C@justtesting.org> <87y4ak4q8u.fsf@smart-cactus.org> <87io1oiljy.fsf@feelingofgreen.ru> <87mvr04f9z.fsf@smart-cactus.org> Message-ID: <87povv2jkp.fsf@smart-cactus.org> Tuncer Ayaz writes: > On 17 February 2016 at 07:40, Evan Laforge wrote: > >> My impression from the reddit thread is that three things are going >> on: >> >> 1 - cabal has quite a bit of startup overhead >> 2 - ghc takes a long time on certain inputs, e.g. long list literals. >> There are probably already tickets for these. > > In my experience GHC startup overhead (time) has increased quite a lot > somewhere in 7.x. I don't know if it's the cause, but perhaps dyn libs > may be part of the reason. I'm not sure because I once (7.8 I believe) > tried to build without dynlink support and couldn't measure a > substantial improvement. > I'm not sure this is going to be a significant effect, but last night thomie, rwbarton, and I discovered that the way we structure the Haskell library directory makes the dynamic linker do significantly more work than necessary. Merely compiling "Hello world" requires 800 `open` system calls with a dynamically linked compiler. Seems like we should really try to fix this. See #11587. 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 ttuegel at gmail.com Wed Feb 17 20:02:18 2016 From: ttuegel at gmail.com (Thomas Tuegel) Date: Wed, 17 Feb 2016 14:02:18 -0600 Subject: Fwd: Is anything being done to remedy the soul crushing compile times of GHC? In-Reply-To: <87egcb4ssc.fsf@smart-cactus.org> References: <4E06663C-C48C-4119-A7A8-8954907B825C@justtesting.org> <87y4ak4q8u.fsf@smart-cactus.org> <87io1oiljy.fsf@feelingofgreen.ru> <87mvr04f9z.fsf@smart-cactus.org> <87egcb4ssc.fsf@smart-cactus.org> Message-ID: On Wed, Feb 17, 2016 at 2:58 AM, Ben Gamari wrote: > Yes, it would be great if someone could step up to look at Cabal's > performance. Running `cabal build` on an up-to-date tree of a > moderately-sized (10 kLoC, 8 components, 60 modules) Haskell project I > have laying around takes over 5 seconds from start-to-finish. > > `cabal build`ing just a single executable component takes 4 seconds. > This same executable takes 48 seconds for GHC to build from scratch with > optimization and 12 seconds without. I have contributed several performance patches to Cabal in the past, so I feel somewhat qualified to speak here. The remaining slowness in `cabal build` is mostly due to the pre-process phase. There work in progress which may improve this situation. We could also look at separating the pre-process phase from the build phase. (It seems odd to call it `pre-process` when it is *always* run during the build phase, doesn't it?) This has the advantage of sidestepping the slowness issue entirely, but it may break some users' workflows. Is that trade-off worth it? We could use user feedback here. Regards, Tom From tuncer.ayaz at gmail.com Wed Feb 17 20:15:05 2016 From: tuncer.ayaz at gmail.com (Tuncer Ayaz) Date: Wed, 17 Feb 2016 21:15:05 +0100 Subject: Fwd: Is anything being done to remedy the soul crushing compile times of GHC? In-Reply-To: References: <4E06663C-C48C-4119-A7A8-8954907B825C@justtesting.org> <87y4ak4q8u.fsf@smart-cactus.org> <87io1oiljy.fsf@feelingofgreen.ru> <87mvr04f9z.fsf@smart-cactus.org> Message-ID: On 17 February 2016 at 14:31, Tuncer Ayaz wrote: > On 17 February 2016 at 07:40, Evan Laforge wrote: > > > My impression from the reddit thread is that three things are going > > on: > > > > 1 - cabal has quite a bit of startup overhead > > 2 - ghc takes a long time on certain inputs, e.g. long list literals. > > There are probably already tickets for these. > > In my experience GHC startup overhead (time) has increased quite a > lot somewhere in 7.x. I don't know if it's the cause, but perhaps > dyn libs may be part of the reason. I'm not sure because I once (7.8 > I believe) tried to build without dynlink support and couldn't > measure a substantial improvement. > > So, if you start ghc(i) for the first time from a spinning disk, > it's very noticeable and quite a delay. Once it's cached, it's fast, > so I think it's primarily due to reading stuff from disk. > > Just to mention the ideal overhead: anything below 400ms is small > enough to not disrupt the flow and feels responsive. Go over 1s and > it breaks. Freshly booted machine with an SSD required 2 seconds for GHCi, so maybe it's just that there's a lot more stuff to load, which leads me to the next question: (better) dead code elimination would probably help, where it at minimum only includes modules used, with a future improvement of skipping unused functions, etc. as well, but I don't know enough about GHC's DCE to talk about it. From qdunkan at gmail.com Wed Feb 17 20:17:15 2016 From: qdunkan at gmail.com (Evan Laforge) Date: Wed, 17 Feb 2016 12:17:15 -0800 Subject: Fwd: Is anything being done to remedy the soul crushing compile times of GHC? In-Reply-To: <1455703870-sup-946@sabre> References: <4E06663C-C48C-4119-A7A8-8954907B825C@justtesting.org> <87y4ak4q8u.fsf@smart-cactus.org> <87io1oiljy.fsf@feelingofgreen.ru> <87mvr04f9z.fsf@smart-cactus.org> <87egcb4ssc.fsf@smart-cactus.org> <1455703870-sup-946@sabre> Message-ID: On Wed, Feb 17, 2016 at 2:14 AM, Edward Z. Yang wrote: > Another large culprit for performance is that the fact that ghc --make > must preprocess and parse the header of every local Haskell file: > https://ghc.haskell.org/trac/ghc/ticket/618 (as well > as https://ghc.haskell.org/trac/ghc/ticket/1290). Neil and I > have observed that when you use something better (like Shake) > recompilation performance gets a lot better, esp. when you > have a lot of modules. I can second this, and I suspect the reason I've never had slowness problems is that I use shake exclusively. I'm looking forward to your work with integrating shake into ghc. If it means we can get both shake's speed and parallelism as well as --make's ability to retain hi files in memory, it should give a really nice speed boost. I see a lot of "compilation IS NOT required", presumably that would be even faster if it didn't have to start a new ghc and inspect all the hi files again before finding that out! From tuncer.ayaz at gmail.com Wed Feb 17 20:18:52 2016 From: tuncer.ayaz at gmail.com (Tuncer Ayaz) Date: Wed, 17 Feb 2016 21:18:52 +0100 Subject: Fwd: Is anything being done to remedy the soul crushing compile times of GHC? In-Reply-To: References: <4E06663C-C48C-4119-A7A8-8954907B825C@justtesting.org> <87y4ak4q8u.fsf@smart-cactus.org> <87io1oiljy.fsf@feelingofgreen.ru> <87mvr04f9z.fsf@smart-cactus.org> Message-ID: On 17 February 2016 at 15:47, Austin Seipp wrote: > The better approach, I think, might be to section off certain times > in a release period where we only allow such changes. Only for a > month or so, for example, and you're just encouraged to park your > current work for a little while, during that time, and just improve > things. > > The only problem is, it's not clear if people will want to commit as > much if the hard rule is just to fix bugs/improve performance for a > select time. Nobody is obligated to contribute, so it could easily > fall into a lull period if people get tired of it. But maybe the > shared sense of community in doing it would help. > > Whatever we do, it has to be strict in these times, because in > practice we have a policy like this ("just bug/perf fixes") during > the time leading up to the RC, but we always slip and merge other > things regardless. So, if we do this, we must be quite strict about > it in practice and police ourselves better, I think. Exactly, the time-boxing aspect is what I tried to express with my concern about even/odd branching model, which failed for linux pre-Bitkeeper. So, maybe a model like Linus does with two weeks of a merge window and then strictly fixes, but that would require a ghc-next branch with a maintainer, so probably not feasible with the resources right now. > On Wed, Feb 17, 2016 at 7:35 AM, Tuncer Ayaz wrote: > > Here's a thought: has anyone experience with limiting a certain > > major release to just bug fixes and perf regression fixes, while > > postponing all feature patches? It sounds like a good idea on > > paper, but has anyone seen it work, and would this be something to > > consider for GHC? I'm not suggesting the even/odd versioning > > scheme, if anyone wonders. These don't work so well and nobody > > tests odd versions. From ben at smart-cactus.org Wed Feb 17 20:21:02 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 17 Feb 2016 21:21:02 +0100 Subject: Fwd: Is anything being done to remedy the soul crushing compile times of GHC? In-Reply-To: References: <4E06663C-C48C-4119-A7A8-8954907B825C@justtesting.org> <87y4ak4q8u.fsf@smart-cactus.org> <87io1oiljy.fsf@feelingofgreen.ru> <87mvr04f9z.fsf@smart-cactus.org> <87egcb4ssc.fsf@smart-cactus.org> Message-ID: <87mvqz2imp.fsf@smart-cactus.org> Thomas Tuegel writes: > On Wed, Feb 17, 2016 at 2:58 AM, Ben Gamari wrote: >> Yes, it would be great if someone could step up to look at Cabal's >> performance. Running `cabal build` on an up-to-date tree of a >> moderately-sized (10 kLoC, 8 components, 60 modules) Haskell project I >> have laying around takes over 5 seconds from start-to-finish. >> >> `cabal build`ing just a single executable component takes 4 seconds. >> This same executable takes 48 seconds for GHC to build from scratch with >> optimization and 12 seconds without. > > I have contributed several performance patches to Cabal in the past, > so I feel somewhat qualified to speak here. The remaining slowness in > `cabal build` is mostly due to the pre-process phase. There work in > progress which may improve this situation. We could also look at > separating the pre-process phase from the build phase. (It seems odd > to call it `pre-process` when it is *always* run during the build > phase, doesn't it?) This has the advantage of sidestepping the > slowness issue entirely, but it may break some users' workflows. Is > that trade-off worth it? We could use user feedback here. > What exactly does the pre-process phase do, anyways? 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 ttuegel at gmail.com Thu Feb 18 00:39:15 2016 From: ttuegel at gmail.com (Thomas Tuegel) Date: Wed, 17 Feb 2016 18:39:15 -0600 Subject: Fwd: Is anything being done to remedy the soul crushing compile times of GHC? In-Reply-To: <87mvqz2imp.fsf@smart-cactus.org> References: <4E06663C-C48C-4119-A7A8-8954907B825C@justtesting.org> <87y4ak4q8u.fsf@smart-cactus.org> <87io1oiljy.fsf@feelingofgreen.ru> <87mvr04f9z.fsf@smart-cactus.org> <87egcb4ssc.fsf@smart-cactus.org> <87mvqz2imp.fsf@smart-cactus.org> Message-ID: On Wed, Feb 17, 2016 at 2:21 PM, Ben Gamari wrote: > Thomas Tuegel writes: >> I have contributed several performance patches to Cabal in the past, >> so I feel somewhat qualified to speak here. The remaining slowness in >> `cabal build` is mostly due to the pre-process phase. There work in >> progress which may improve this situation. We could also look at >> separating the pre-process phase from the build phase. (It seems odd >> to call it `pre-process` when it is *always* run during the build >> phase, doesn't it?) This has the advantage of sidestepping the >> slowness issue entirely, but it may break some users' workflows. Is >> that trade-off worth it? We could use user feedback here. >> > What exactly does the pre-process phase do, anyways? It runs the appropriate pre-processor (Alex, Happy, c2hs, etc.) for modules that require it. It's slow because of the way the process is carried out: For each module in the package description, Cabal tries to find an associated .hs source file in the hs-source-dirs. If it cannot, it looks for a file with an extension matching one of the pre-processors it knows about. If it finds one, it runs the corresponding program if the output files are missing or outdated. If this doesn't sound TOO bad, consider: how many modules on Hackage use pre-processors? Certainly less than 5%, maybe even less than 1%. That's a LOT of work every time you call `cabal build`. - Tom P.S. If I may get a little philosophical, this is representative of the problems we have in Cabal. Cabal tries to be very automagical, at the cost of being sometimes slow and always opaque when things break! From chak at justtesting.org Thu Feb 18 02:20:58 2016 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Thu, 18 Feb 2016 13:20:58 +1100 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: References: <87egcg93zn.fsf@smart-cactus.org> <1455381609.2134.16.camel@gmail.com> <87si0u6y9h.fsf@smart-cactus.org> <8737st6iyg.fsf@smart-cactus.org> <98EE8A62-8397-4D21-ABB4-63D4604D7062@cis.upenn.edu> <9723F5A2-8FA7-4389-AE55-B46481748216@justtesting.org> Message-ID: > Christopher Allen : > > Sorry for the mostly off-topic post, but since a beginner?s Prelude was mentioned here multiple times recently as a countermeasure to making the real Prelude more complicated, I just want to say, don?t put too much hope into a ?solution? you never actually tried. > > I have tried a beginner's Prelude with people. I don't have a lot of data because it was clearly a failure early on so I bailed them out into the usual thing. It's just not worth it and it deprives them of the preparedness to go write real Haskell code. That?s not something I'm willing to give up just so I can teach _less_. That is a valuable data point. Thanks! Manuel From chak at justtesting.org Thu Feb 18 02:38:33 2016 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Thu, 18 Feb 2016 13:38:33 +1100 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: References: <87egcg93zn.fsf@smart-cactus.org> <1455381609.2134.16.camel@gmail.com> <87si0u6y9h.fsf@smart-cactus.org> <8737st6iyg.fsf@smart-cactus.org> <98EE8A62-8397-4D21-ABB4-63D4604D7062@cis.upenn.edu> <9723F5A2-8FA7-4389-AE55-B46481748216@justtesting.org> Message-ID: Hi Takenobu, > Takenobu Tani : > > Hi Manuel, > > > * Introduce the concept of overloading right away. People get that easily, > > because they use overloaded arithmetic functions in math, too. > > (Num and Show are the typical classes to explain it at.) > > As an example, see how we do that in the first chapter of our new Haskell > > tutorial: http://learn.hfm.io/first_steps.html > > This is straightforward and elegance tutorial! I like this. You are very kind. Thank you. > As you know, I'll share one point to list. > > It's better to assume that "beginners are not only students in universities". > Beginners are also engineers, hobbyist, teenager, your friends and your family. > Someone of them will touch to Haskell alone and learn with self study > in a little bit of knowledge. > > If they feel complex at first impression in their 1st week, > they would go back before they realize beauty of Haskell. > > Sometimes, I?m worried about it. I do worry about the same thing. The Haskell ecosystem is very much geared towards experts and tinkerers (with laudable exceptions, such as, for example, the great work done by Chris Allen). Being an expert and tinkerer that didn?t worry me too much, but lately I am trying to make functional programming and Haskell accessible to a broader audience and it is an uphill battle. Even many professional software developers are put off even trying to install the toolchain. It is not that they wouldn?t been able to do it if they wanted. They just can?t be bothered because they are not convinced of the value of doing so at this stage ? exactly as you are saying. We should make it easier to get started, not harder. Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at seidel.io Thu Feb 18 03:02:24 2016 From: eric at seidel.io (Eric Seidel) Date: Wed, 17 Feb 2016 19:02:24 -0800 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: References: <87egcg93zn.fsf@smart-cactus.org> <1455381609.2134.16.camel@gmail.com> <87si0u6y9h.fsf@smart-cactus.org> <8737st6iyg.fsf@smart-cactus.org> <98EE8A62-8397-4D21-ABB4-63D4604D7062@cis.upenn.edu> <9723F5A2-8FA7-4389-AE55-B46481748216@justtesting.org> Message-ID: <1455764544.2889103.524482378.1C9DA511@webmail.messagingengine.com> On Wed, Feb 17, 2016, at 08:09, Christopher Allen wrote: > I have tried a beginner's Prelude with people. I don't have a lot of data > because it was clearly a failure early on so I bailed them out into the > usual thing. It's just not worth it and it deprives them of the > preparedness to go write real Haskell code. That's not something I'm > willing to give up just so I can teach _less_. Chris, have you written about your experiences teaching with a beginner's Prelude? I'd be quite interested to read about it, as (1) it seems like a natural thing to do and (2) the Racket folks seem to have had good success with their staged teaching languages. In particular, I'm curious if your experience is in the context of teaching people with no experience programming at all, vs programming experience but no Haskell (or generally FP) experience. The Racket "How to Design Programs" curriculum seems very much geared towards absolute beginners, and that could be a relevant distinction. Thanks! Eric From hvriedel at gmail.com Thu Feb 18 07:45:55 2016 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Thu, 18 Feb 2016 08:45:55 +0100 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: <1455764544.2889103.524482378.1C9DA511@webmail.messagingengine.com> (Eric Seidel's message of "Wed, 17 Feb 2016 19:02:24 -0800") References: <87egcg93zn.fsf@smart-cactus.org> <1455381609.2134.16.camel@gmail.com> <87si0u6y9h.fsf@smart-cactus.org> <8737st6iyg.fsf@smart-cactus.org> <98EE8A62-8397-4D21-ABB4-63D4604D7062@cis.upenn.edu> <9723F5A2-8FA7-4389-AE55-B46481748216@justtesting.org> <1455764544.2889103.524482378.1C9DA511@webmail.messagingengine.com> Message-ID: <87si0qfolo.fsf@gmail.com> On 2016-02-18 at 04:02:24 +0100, Eric Seidel wrote: > On Wed, Feb 17, 2016, at 08:09, Christopher Allen wrote: >> I have tried a beginner's Prelude with people. I don't have a lot of data >> because it was clearly a failure early on so I bailed them out into the >> usual thing. It's just not worth it and it deprives them of the >> preparedness to go write real Haskell code. That's not something I'm >> willing to give up just so I can teach _less_. > > Chris, have you written about your experiences teaching with a > beginner's Prelude? I'd be quite interested to read about it, as (1) it > seems like a natural thing to do and (2) the Racket folks seem to have > had good success with their staged teaching languages. > > In particular, I'm curious if your experience is in the context of > teaching people with no experience programming at all, vs programming > experience but no Haskell (or generally FP) experience. The Racket "How > to Design Programs" curriculum seems very much geared towards absolute > beginners, and that could be a relevant distinction. Btw, IMHO it's also interesting to distinguish between teaching functional programming vs teaching Haskell. I've noticed that in the former case, instructors would often prefer a radically slimmed down standard-library and conceal some of Haskell's language features not pertinent to their FP curriculum (e.g. typeclasses or record syntax). -- From simonpj at microsoft.com Thu Feb 18 10:42:06 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 18 Feb 2016 10:42:06 +0000 Subject: Strict Haskell Message-ID: <7afa774469b44fc2b1801764624f1f61@DB4PR30MB030.064d.mgd.msft.net> Johan Consider this with -XStrict f y = let Just x = blah[y] in body[y,x] Suppose that in a call to f, ? blah returns Nothing ? but body does not use x Should f succeed? For sure, blah will be evaluated to HNF before body is started, but is the match against Just done strictly too? According to our current semantics, in the match against Just is not done strictly, so the call should succeed. I think that?s unexpected and probably wrong. Here?s the semantics http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#recursive-and-polymorphic-let-bindings The translation for !(Just x) = blah ? (FORCE) v = blah; Just x = v (and add a seq on v) ? (SPLIT) v = blah; x = case v of Just x -> x So we finish up with f y = let v = blah[y] in let x = case v of Just x -> x in v `seq` body[y,x] I don?t think that?s what you intended. If the pattern can fail, I think we want the FORCE step to say this: Replace any binding !p = e with v = case e of p -> (v1,..,vn); (v1,..,vn) = v and replace e0 with v seq e0, where v is fresh and v1..vn are the variable(s) bound by p (Compare with the text at the above link.) Do you agree? Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrey.mokhov at newcastle.ac.uk Thu Feb 18 12:32:59 2016 From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov) Date: Thu, 18 Feb 2016 12:32:59 +0000 Subject: Fwd: Is anything being done to remedy the soul crushing compile times of GHC? Message-ID: Thomas Tuegel writes: > > What exactly does the pre-process phase do, anyways? > It runs the appropriate pre-processor (Alex, Happy, c2hs, etc.) for modules > that require it. It's slow because of the way the process is carried out: For > each module in the package description, Cabal tries to find an associated .hs > source file in the hs-source-dirs. If it cannot, it looks for a file with an > extension matching one of the pre-processors it knows about. If it finds one, > it runs the corresponding program if the output files are missing or outdated. Interesting! In the new Shake-based build system we also need to automagically generate .hs files using Alex et al. My first implementation was slow but then I realised that it is possible to scan the source tree only once and remember where all .hs/.x/etc files are. This brought down the complexity from quadratic to linear in my case -- maybe this could be reused in cabal too? By the way, there seem to be a fair amount of code & functionality overlap in cabal and the new build system. We might want to look into this once the build system becomes more stable. Cheers, Andrey From hvriedel at gmail.com Thu Feb 18 12:43:00 2016 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Thu, 18 Feb 2016 13:43:00 +0100 Subject: Fwd: Is anything being done to remedy the soul crushing compile times of GHC? In-Reply-To: (Andrey Mokhov's message of "Thu, 18 Feb 2016 12:32:59 +0000") References: Message-ID: <87oabefauj.fsf@gmail.com> On 2016-02-18 at 13:32:59 +0100, Andrey Mokhov wrote: [...] > Interesting! In the new Shake-based build system we also need to > automagically generate .hs files using Alex et al. My first > implementation was slow but then I realised that it is possible to > scan the source tree only once and remember where all .hs/.x/etc files > are. This brought down the complexity from quadratic to linear in my > case -- maybe this could be reused in cabal too? This sounds very risky; are you suggesting to blindly traverse the hs-src-dirs *before* you even know what is searched for? If so, this will cause problems; we're already seeing problems with this in the cabal nix-local-branch, which currently (it's a bug) recursively traverses the project folder for computing a source-hash over content that would not even make it into the source-dist... There must be a better way to solve this... From takenobu.hs at gmail.com Thu Feb 18 13:01:19 2016 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Thu, 18 Feb 2016 22:01:19 +0900 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: References: <87egcg93zn.fsf@smart-cactus.org> <1455381609.2134.16.camel@gmail.com> <87si0u6y9h.fsf@smart-cactus.org> <8737st6iyg.fsf@smart-cactus.org> <98EE8A62-8397-4D21-ABB4-63D4604D7062@cis.upenn.edu> <9723F5A2-8FA7-4389-AE55-B46481748216@justtesting.org> Message-ID: Hi Manuel, > I do worry about the same thing. The Haskell ecosystem is very much geared towards experts and tinkerers (with laudable exceptions, such as, for example, the great work done by Chris Allen). Being an expert and tinkerer that didn?t worry me too much, but lately I am trying to make functional programming and Haskell accessible to a broader audience and it is an uphill battle. Even many professional software developers are put off even trying to install the toolchain. It is not that they wouldn?t been able to do it if they wanted. They just can?t be bothered because they are not convinced of the value of doing so at this stage ? exactly as you are saying. > > We should make it easier to get started, not harder. You are thinking deeply. We should find approaches that satisfy the follows: * No surprise for various beginners * No confuse by their step-up * No stress for experts * No prevent GHC(Haskell)'s evolution I like diversity of Haskell community =) Regards, Takenobu -------------- next part -------------- An HTML attachment was scrubbed... URL: From takenobu.hs at gmail.com Thu Feb 18 13:09:49 2016 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Thu, 18 Feb 2016 22:09:49 +0900 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: <87si0qfolo.fsf@gmail.com> References: <87egcg93zn.fsf@smart-cactus.org> <1455381609.2134.16.camel@gmail.com> <87si0u6y9h.fsf@smart-cactus.org> <8737st6iyg.fsf@smart-cactus.org> <98EE8A62-8397-4D21-ABB4-63D4604D7062@cis.upenn.edu> <9723F5A2-8FA7-4389-AE55-B46481748216@justtesting.org> <1455764544.2889103.524482378.1C9DA511@webmail.messagingengine.com> <87si0qfolo.fsf@gmail.com> Message-ID: Hi, I know the issue of beginner's Prelude. But how about "profile"? (like H264/MPEG4-AVC profile [1]) * Beginner Profile : beginner's Prelude or ghci beginner's representation mode * Main Profile : Haskell 2010 standard * Leading edge Profile : set of GHC extensions If beginners know exist of profile at first, they may avoid to confuse by step-up? More confused? Already we implicitly have at least two profiles (Haskell2010 and GHC extensions). [1] https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles Regards, Takenobu 2016-02-18 16:45 GMT+09:00 Herbert Valerio Riedel : > On 2016-02-18 at 04:02:24 +0100, Eric Seidel wrote: > > On Wed, Feb 17, 2016, at 08:09, Christopher Allen wrote: > >> I have tried a beginner's Prelude with people. I don't have a lot of > data > >> because it was clearly a failure early on so I bailed them out into the > >> usual thing. It's just not worth it and it deprives them of the > >> preparedness to go write real Haskell code. That's not something I'm > >> willing to give up just so I can teach _less_. > > > > Chris, have you written about your experiences teaching with a > > beginner's Prelude? I'd be quite interested to read about it, as (1) it > > seems like a natural thing to do and (2) the Racket folks seem to have > > had good success with their staged teaching languages. > > > > In particular, I'm curious if your experience is in the context of > > teaching people with no experience programming at all, vs programming > > experience but no Haskell (or generally FP) experience. The Racket "How > > to Design Programs" curriculum seems very much geared towards absolute > > beginners, and that could be a relevant distinction. > > Btw, IMHO it's also interesting to distinguish between teaching > functional programming vs teaching Haskell. > > I've noticed that in the former case, instructors would often prefer a > radically slimmed down standard-library and conceal some of Haskell's > language features not pertinent to their FP curriculum (e.g. typeclasses > or record syntax). > > -- > _______________________________________________ > 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 ttuegel at gmail.com Thu Feb 18 13:27:15 2016 From: ttuegel at gmail.com (Thomas Tuegel) Date: Thu, 18 Feb 2016 07:27:15 -0600 Subject: Fwd: Is anything being done to remedy the soul crushing compile times of GHC? In-Reply-To: <87oabefauj.fsf@gmail.com> References: <87oabefauj.fsf@gmail.com> Message-ID: On Thu, Feb 18, 2016 at 6:43 AM, Herbert Valerio Riedel wrote: > On 2016-02-18 at 13:32:59 +0100, Andrey Mokhov wrote: >> Interesting! In the new Shake-based build system we also need to >> automagically generate .hs files using Alex et al. My first >> implementation was slow but then I realised that it is possible to >> scan the source tree only once and remember where all .hs/.x/etc files >> are. This brought down the complexity from quadratic to linear in my >> case -- maybe this could be reused in cabal too? > > This sounds very risky; are you suggesting to blindly traverse the > hs-src-dirs *before* you even know what is searched for? > > If so, this will cause problems; we're already seeing problems with this > in the cabal nix-local-branch, which currently (it's a bug) recursively > traverses the project folder for computing a source-hash over content > that would not even make it into the source-dist... > > There must be a better way to solve this... I think what Andrey meant was, the first time we run the pre-processors, cache the locations of all the files that need to be pre-processed. On subsequent runs, we only need to check pre-processors the files in the cache. I've been thinking along these lines, too. This does break if you change what pre-processor is used to build a file, but I think that's OK because it happens so rarely. We would give the user a way to invalidate the cache, i.e. run the pre-processors manually by a `cabal pre-process` command. - Tom From andrey.mokhov at newcastle.ac.uk Thu Feb 18 13:59:25 2016 From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov) Date: Thu, 18 Feb 2016 13:59:25 +0000 Subject: Fwd: Is anything being done to remedy the soul crushing compile times of GHC? In-Reply-To: References: <87oabefauj.fsf@gmail.com> Message-ID: Thomas Tuegel writes: > I think what Andrey meant was, the first time we run the pre-processors, > cache the locations of all the files that need to be pre-processed. On > subsequent runs, we only need to check pre-processors the files in the cache. Yes, something along the lines. Although I don't fully understand Herbert's comment, so I decided to open an issue about this so we could discuss this without spamming the ghc-devs mailing list: https://github.com/snowleopard/shaking-up-ghc/issues/210 Herbert, Thomas, and all -- I'd appreciate your input! Cheers, Andrey From david.feuer at gmail.com Thu Feb 18 17:00:46 2016 From: david.feuer at gmail.com (David Feuer) Date: Thu, 18 Feb 2016 12:00:46 -0500 Subject: Missing definitions of associated types Message-ID: It seems to be that a missing associated type definition should be an error, by default, rather than a warning. The current behavior under those circumstances strikes me as very strange, particularly for data families and particularly in the presence of overlapping. {-# LANGUAGE TypeFamilies #-} class Foo a where data Assoc a foo :: proxy a -> Assoc a instance {-# OVERLAPPABLE #-} Foo a where data Assoc a = AssocGeneral foo _ = AssocGeneral instance {-# OVERLAPS #-} Foo Char where foo _ = AssocGeneral blah :: Assoc Char blah = foo (Proxy :: Proxy Char) This compiles with just a warning because Assoc Char *falls through* to the general case. WAT? This breaks all my intuition about what associated types are supposed to be about. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwbarton at gmail.com Thu Feb 18 17:49:30 2016 From: rwbarton at gmail.com (Reid Barton) Date: Thu, 18 Feb 2016 12:49:30 -0500 Subject: Missing definitions of associated types In-Reply-To: References: Message-ID: Well, I see your point; but you also can't define a On Thu, Feb 18, 2016 at 12:00 PM, David Feuer wrote: > It seems to be that a missing associated type definition should be an > error, by default, rather than a warning. The current behavior under those > circumstances strikes me as very strange, particularly for data families > and particularly in the presence of overlapping. > > This compiles with just a warning because Assoc Char *falls through* to > the general case. WAT? This breaks all my intuition about what associated > types are supposed to be about. > > Well, I see your point; but you also can't give a definition for Assoc Char in the Foo Char instance, because open data family instances are not allowed to overlap. So if failing to give a definition for an associated data family is an error, then it's impossible to use overlapping instances with classes that have associated data families. Is that your intention? I don't have a strong opinion here. I'm mildly inclined to say that people using overlapping instances have already signed themselves up for weird things happening, and we may as well let them do whatever other weird things they want. Regards, Reid Barton -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasmiedema at gmail.com Thu Feb 18 18:40:50 2016 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Thu, 18 Feb 2016 19:40:50 +0100 Subject: Build failures with -DDEBUG Message-ID: Simon, the commits you pushed today don't validate with -DDEBUG. Unexpected failures: patsyn/should_compile MoreEx [exit code non-0] (normal) patsyn/should_compile T11224b [exit code non-0] (normal) polykinds MonoidsTF [exit code non-0] (normal) polykinds T11480b [exit code non-0] (normal) polykinds T11523 [exit code non-0] (normal) typecheck/should_fail TcCoercibleFail [stderr mismatch] (normal) TcCoercibleFail timed out, and the others all hit the following debug assert: =====> T11224b(normal) 2510 of 5029 [0, 0, 0] Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160218 for x86_64-unknown-linux): ASSERT failed! CallStack (from HasCallStack): assertPprPanic, called at compiler/types/TyCoRep.hs:1932:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:1991:17 in ghc:TyCoRep substTys, called at compiler/types/TyCoRep.hs:2012:14 in ghc:TyCoRep substTheta, called at compiler/typecheck/TcPatSyn.hs:255:20 in ghc:TcPatSyn in_scope InScope {d_ap0 c_apv} tenv [ap1 :-> c_apv[tau:5]] tenvFVs [aps :-> t_aps[tau:1], apv :-> c_apv[tau:5]] cenv [] cenvFVs [] tys [] cos [] Complete log from Travis: https://s3.amazonaws.com/archive.travis-ci.org/jobs/110115377/log.txt -- Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Feb 18 19:10:23 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 18 Feb 2016 19:10:23 +0000 Subject: Build failures with -DDEBUG In-Reply-To: References: Message-ID: <547f88b0edfc47e5a5bd0c806aed3fd5@DB4PR30MB030.064d.mgd.msft.net> Very helpful thanks. TcCoercibleFail is known to time out (for decent reasons) with ?DDEBUG (see comments in the dsource file) I?l look into the PatSyn thing Simon From: Thomas Miedema [mailto:thomasmiedema at gmail.com] Sent: 18 February 2016 18:41 To: Simon Peyton Jones ; ghc-devs at haskell.org Subject: Build failures with -DDEBUG Simon, the commits you pushed today don't validate with -DDEBUG. Unexpected failures: patsyn/should_compile MoreEx [exit code non-0] (normal) patsyn/should_compile T11224b [exit code non-0] (normal) polykinds MonoidsTF [exit code non-0] (normal) polykinds T11480b [exit code non-0] (normal) polykinds T11523 [exit code non-0] (normal) typecheck/should_fail TcCoercibleFail [stderr mismatch] (normal) TcCoercibleFail timed out, and the others all hit the following debug assert: =====> T11224b(normal) 2510 of 5029 [0, 0, 0] Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160218 for x86_64-unknown-linux): ASSERT failed! CallStack (from HasCallStack): assertPprPanic, called at compiler/types/TyCoRep.hs:1932:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:1991:17 in ghc:TyCoRep substTys, called at compiler/types/TyCoRep.hs:2012:14 in ghc:TyCoRep substTheta, called at compiler/typecheck/TcPatSyn.hs:255:20 in ghc:TcPatSyn in_scope InScope {d_ap0 c_apv} tenv [ap1 :-> c_apv[tau:5]] tenvFVs [aps :-> t_aps[tau:1], apv :-> c_apv[tau:5]] cenv [] cenvFVs [] tys [] cos [] Complete log from Travis: https://s3.amazonaws.com/archive.travis-ci.org/jobs/110115377/log.txt -- Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Thu Feb 18 19:22:30 2016 From: david.feuer at gmail.com (David Feuer) Date: Thu, 18 Feb 2016 14:22:30 -0500 Subject: Missing definitions of associated types In-Reply-To: References: Message-ID: You make a good point about people who use overlapping instances deserving whatever they get (I'd personally love to see that whole mess removed and replaced with something less intrusive). The bit that most severely breaks my intuition here is that under normal, well-behaved circumstances, every instance of a class with associated data has its own distinct associated type(s). That is, there is a one-to-many relationship between instances and types. When a definition is missing, that breaks, and the relationship may become many-to-many. I suppose we may need to settle for this as long as overlapping instances in their present form are around. On Feb 18, 2016 12:49 PM, "Reid Barton" wrote: > Well, I see your point; but you also can't define a > > On Thu, Feb 18, 2016 at 12:00 PM, David Feuer > wrote: > >> It seems to be that a missing associated type definition should be an >> error, by default, rather than a warning. The current behavior under those >> circumstances strikes me as very strange, particularly for data families >> and particularly in the presence of overlapping. >> > >> This compiles with just a warning because Assoc Char *falls through* to >> the general case. WAT? This breaks all my intuition about what associated >> types are supposed to be about. >> >> > Well, I see your point; but you also can't give a definition for Assoc > Char in the Foo Char instance, because open data family instances are not > allowed to overlap. So if failing to give a definition for an associated > data family is an error, then it's impossible to use overlapping instances > with classes that have associated data families. Is that your intention? > > I don't have a strong opinion here. I'm mildly inclined to say that people > using overlapping instances have already signed themselves up for weird > things happening, and we may as well let them do whatever other weird > things they want. > > Regards, > Reid Barton > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anselm.scholl at tu-harburg.de Fri Feb 19 11:13:40 2016 From: anselm.scholl at tu-harburg.de (Jonas Scholl) Date: Fri, 19 Feb 2016 12:13:40 +0100 Subject: Advice for #11475 Message-ID: <56C6F8E4.4040609@tu-harburg.de> Hello GHC-Devs, I am currently giving #11475 a try. However I hit a few problems and wanted to ask for a bit of advice about how to proceed. I already can handle the following: case x of A y -> e1 _ -> ....(case x of B -> r2 C -> r3) ... My first problem then was the following construct: case (case ... of ... -> Left x) of Left y -> ... Or more simple: case Left x of Left y -> ... So I have to check which constructors the scrutinee may return. I know the simplifier has to implement such logic somewhere but did not want to use the implementation for two reasons: - I didn't know where to find it - If GHC uses the same test to prune impossible alternatives and to check if they were pruned correctly, extending the linter is useless. A bug in the test code will cause also cause a bug in the linter. So I implemented such a test myself, but now I am stuck at something like this: foo a b = a : b bar = ... case foo a b of (:) x y -> ... I cannot see through foo, so I assume it may return (:) and []. The simplifier on the other hand is able to see through foo and did remove the [] case, causing my current implementation to throw an incorrect lint error. How can I get a list/set of all possible AltCons returned by a function/constant? Or a list of the impossible ones? I tried to get some information from the unfolding of a variable, but it seems like unfoldings are only attached to top-level names. Jonas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From omeragacan at gmail.com Fri Feb 19 17:27:29 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Fri, 19 Feb 2016 12:27:29 -0500 Subject: 'lub' and 'both' on strictness - what does it mean for products to have different arity? Message-ID: I was looking at implementations of LUB and AND on demand signatures and I found this interesting case: lubStr (SProd s1) (SProd s2) | length s1 == length s2 = mkSProd (zipWith lubArgStr s1 s2) | otherwise = HeadStr The "otherwise" case is interesting, I'd expect that to be an error. I'm trying to come up with an example, let's say I have a case expression: case x of P1 -> RHS1 P2 -> RHS2 and y is used in RHS1 with S(SS) and in RHS2 with S(SSS). This seems to me like a type error leaked into the demand analysis. Same thing applies to `bothDmd` too. Funnily, it has this extra comment on this same code: bothStr (SProd s1) (SProd s2) | length s1 == length s2 = mkSProd (zipWith bothArgStr s1 s2) | otherwise = HyperStr -- Weird Does "Weird" here means "type error and/or bug" ? Should I try replacing these cases with panics and try to validate? From eir at cis.upenn.edu Fri Feb 19 22:21:47 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 19 Feb 2016 17:21:47 -0500 Subject: Advice for #11475 In-Reply-To: <56C6F8E4.4040609@tu-harburg.de> References: <56C6F8E4.4040609@tu-harburg.de> Message-ID: <13E0BA8C-0856-45A2-8DD7-23C535243EAD@cis.upenn.edu> Hi Jonas, Thanks for jumping in! It sounds like you're very much on the right track here, and I appreciate your desire not to use the simplifier code in the linter. I'm afraid I don't have good answers for your questions, however. Really, this email is just to offer some gratitude and hope you can wait for someone more knowledgeable about the simplifier (e.g., SPJ) to answer. I have to say that I'm worried here that the Right Answer will involve having the simplifier produce some evidence for its pruning ideas, so that the linter can simply verify the evidence. This evidence would be in the form of a small data structure with constructors that say "looked through identifier <>" or "scrutinee is a constructor call of <>" or similar. Then the linter's job is made much easier. Richard On Feb 19, 2016, at 6:13 AM, Jonas Scholl wrote: > Hello GHC-Devs, > > I am currently giving #11475 a try. However I hit a few problems and > wanted to ask for a bit of advice about how to proceed. > > I already can handle the following: > > case x of > A y -> e1 > _ -> ....(case x of > B -> r2 > C -> r3) ... > > My first problem then was the following construct: > > case (case ... of ... -> Left x) of > Left y -> ... > > Or more simple: > > case Left x of > Left y -> ... > > So I have to check which constructors the scrutinee may return. I know > the simplifier has to implement such logic somewhere but did not want to > use the implementation for two reasons: > - I didn't know where to find it > - If GHC uses the same test to prune impossible alternatives and to > check if they were pruned correctly, extending the linter is useless. A > bug in the test code will cause also cause a bug in the linter. > > So I implemented such a test myself, but now I am stuck at something > like this: > > foo a b = a : b > > bar = ... case foo a b of > (:) x y -> ... > > I cannot see through foo, so I assume it may return (:) and []. The > simplifier on the other hand is able to see through foo and did remove > the [] case, causing my current implementation to throw an incorrect > lint error. > > How can I get a list/set of all possible AltCons returned by a > function/constant? Or a list of the impossible ones? I tried to get some > information from the unfolding of a variable, but it seems like > unfoldings are only attached to top-level names. > > Jonas > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From marek.28.93 at gmail.com Sat Feb 20 08:39:55 2016 From: marek.28.93 at gmail.com (Marek Wawrzos) Date: Sat, 20 Feb 2016 09:39:55 +0100 Subject: Fwd: Compiling Core Haskell using GHC API In-Reply-To: <1444323665-sup-2038@sabre> References: <1444323665-sup-2038@sabre> Message-ID: Hello, I am bringing back that thread to life after a while. I've spent some time on studding GHC source code related with that topic. There are some conclusions I have made: - In my first email, I thought that execution of function *compileCoreToObj *in my program produced some *.o file. I was wrong. That file was produced by earlier step, that is execution of *compileToCoreModule *function. *compileCoreToObj *has generated only *.hi file because exception has been raised. - I have found a way to produce valid interface file - I have discovered, why *compileCoreToObj *raises exceptions. It was because *stubDir* field in *DynFlags *structure has to be set for proper execution. - Artifacts produced by *compileCoreToObj *for a non-executable module are: interface file and assembly output. The last point is my main problem for now. I supposed that object file will be generated, as it is generated by GHC executed on haskell module. Code used for my tests is as follows: A.hs: import GHC > import DynFlags > import GHC.Paths > import qualified Debug.Trace as T > import Panic > import HscMain > import HscTypes > import Name > import UniqFM > main = do > core <- getCore > getLine > compile HscAsm "foo" core > getCore = defaultErrorHandler defaultFatalMessager defaultFlushOut > $ runGhc (Just libdir) $ do > df <- getSessionDynFlags > setSessionDynFlags df > core <- compileToCoreModule "B.hs" > return core > compile target output_fn core = defaultErrorHandler defaultFatalMessager > defaultFlushOut > $ runGhc (Just libdir) $ do > df <- getSessionDynFlags > setSessionDynFlags df { hscTarget = target , stubDir = Just > "./stub" } compileCoreToObj False core output_fn "bar" B.hs: > module B (foo) where > foo :: a -> a > foo = id > bar :: Eq a => a -> a -> Bool > bar = (==) *getCore *and *compile* are separated to make sure, no flags set by the first function were used by the second one. *getLine *is used here to stop an execution of test for cleaning output directory form files generated by *getCore*. Is there a way to get an object file as a result of *compileCoreToObj*? Regards, MWawrzos 2015-10-08 19:02 GMT+02:00 Edward Z. Yang : > 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 > -- Z powa?aniem, Marek Wawrzos -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Sat Feb 20 19:55:43 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Sat, 20 Feb 2016 11:55:43 -0800 Subject: Fwd: Compiling Core Haskell using GHC API In-Reply-To: References: <1444323665-sup-2038@sabre> Message-ID: <1455998125-sup-3633@sabre> What version of GHC are you working with? I don't see any compileCoreToObj function in HEAD. Edward Excerpts from Marek Wawrzos's message of 2016-02-20 00:39:55 -0800: > Hello, > > I am bringing back that thread to life after a while. > > I've spent some time on studding GHC source code related with that topic. > There are some conclusions I have made: > > - In my first email, I thought that execution of function > *compileCoreToObj *in my program produced some *.o file. I was wrong. > That file was produced by earlier step, that is execution of > *compileToCoreModule > *function. *compileCoreToObj *has generated only *.hi file because > exception has been raised. > - I have found a way to produce valid interface file > - I have discovered, why *compileCoreToObj *raises exceptions. It was > because *stubDir* field in *DynFlags *structure has to be set for proper > execution. > - Artifacts produced by *compileCoreToObj *for a non-executable module are: > interface file and assembly output. > > The last point is my main problem for now. I supposed that object file will > be generated, as it is generated by GHC executed on haskell module. > Code used for my tests is as follows: > > A.hs: > > import GHC > > import DynFlags > > import GHC.Paths > > import qualified Debug.Trace as T > > import Panic > > import HscMain > > import HscTypes > > import Name > > import UniqFM > > main = do > > core <- getCore > > getLine > > compile HscAsm "foo" core > > getCore = defaultErrorHandler defaultFatalMessager defaultFlushOut > > $ runGhc (Just libdir) $ do > > df <- getSessionDynFlags > > setSessionDynFlags df > > core <- compileToCoreModule "B.hs" > > return core > > compile target output_fn core = defaultErrorHandler defaultFatalMessager > > defaultFlushOut > > $ runGhc (Just libdir) $ do > > df <- getSessionDynFlags > > setSessionDynFlags df { hscTarget = target , stubDir = Just > > "./stub" } > > compileCoreToObj False core output_fn "bar" > > B.hs: > > > module B (foo) where > > foo :: a -> a > > foo = id > > bar :: Eq a => a -> a -> Bool > > bar = (==) > > > *getCore *and *compile* are separated to make sure, no flags set by the > first function were used by the second one. > *getLine *is used here to stop an execution of test for cleaning output > directory form files generated by *getCore*. > > Is there a way to get an object file as a result of *compileCoreToObj*? > > Regards, > MWawrzos > > 2015-10-08 19:02 GMT+02:00 Edward Z. Yang : > > > 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 mail at joachim-breitner.de Sat Feb 20 22:02:01 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 20 Feb 2016 23:02:01 +0100 Subject: 'lub' and 'both' on strictness - what does it mean for products to have different arity? In-Reply-To: References: Message-ID: <1456005721.4636.5.camel@joachim-breitner.de> Hi, Am Freitag, den 19.02.2016, 12:27 -0500 schrieb ?mer Sinan A?acan: > Should I try replacing these cases with panics and try to validate? of course you can, but I have seen cases where due to type families and stuff you can have a type-correct program that ?looks wrongly typed? from the point of view of the strictness analyzer. So in these cases it is indeed the right thing to throw away the conflicting information and continue. Greetings, Joachim -- Joachim ?nomeata? Breitner ? mail at joachim-breitner.de ? https://www.joachim-breitner.de/ ? XMPP: nomeata at joachim-breitner.de?? OpenPGP-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 jmct at jmct.cc Sat Feb 20 23:01:40 2016 From: jmct at jmct.cc (=?UTF-8?Q?Jos=C3=A9_Manuel_Calder=C3=B3n_Trilla?=) Date: Sat, 20 Feb 2016 18:01:40 -0500 Subject: Generalising the demand analysis to sum types In-Reply-To: <5ef58ac4619940608835ec3662591316@DB4PR30MB030.064d.mgd.msft.net> References: <5ef58ac4619940608835ec3662591316@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Hello again, The way I see it, the information would allow us to automatically unbox the arguments to constructors in sum types. For example, with a Maybe Int, you would be able to automatically unpack the Int within the Just constructor whenever the strictness analysis determines that a function is strict in Just's argument. Currently we can't determine any strictness greater than HeadStr for sum types, which would not give us this information (since HeadStr means it's only safe the evaluate up to the outermost constructor; 'Just' in this case). Combining this with the unboxed sums work, the idea is to be able to not only unbox the sum, but the fields of a constructor when possible, removing as many indirections as possible. At least, that's the plan :) Cheers, Jose On Wed, Feb 17, 2016 at 9:09 AM, Simon Peyton Jones wrote: > I think you could do that. The key question is (as someone asked) what use you would make of the information. That is, what's the payoff? > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Jos? > | Manuel Calder?n Trilla > | Sent: 17 February 2016 04:50 > | To: ghc-devs at haskell.org > | Subject: Generalising the demand analysis to sum types > | > | Hello ghc-devs, > | > | Apologies for the longish email. > | > | I'm looking to generalise GHC's demand analysis to work on sum types. > | This is in connection with the work on unboxed sums. The idea is that > | if the strictness analysis tells us that a sum type is strict in all > | the fields of all of its constructors, it is safe to unbox that sum > | automatically. We hope for this to feed into a worker/wrapper like > | transformation for sum types. > | > | I am new to the GHC codebase and wanted to make sure that my plan of > | attack seemed sensible to you all. > | > | GHC's current type representing demand is StrDmd, which is defined as > | follows: > | > | data StrDmd > | = HyperStrict > | | SCall StrDmd > | | SProd [ArgStr] > | | HeadStr > | > | I believe that adding sum types will be as simple as adding a single > | new constructor for Sums: > | > | data StrDmd > | = HyperStrict > | | SCall StrDmd > | | SProd [ArgStr] > | | SSum [(Tag, StrDmd)] > | | HeadStr > | > | We need the constructor tag so that we can analyze each branch of a > | case expression independently before combining the results of each > | branch. Since we only care if all fields are strict for all > | constructors, we won't actually use the tag information except in the > | analysis itself. > | > | Projection-based strictness analysis on sum types is not new (though > | sum types + higher-order seems to be). That being said, all previous > | treatments of the subject that I'm aware of forbid polymorphic > | recursion. Luckily for us we aren't trying to unbox recursive types, so > | for now [1] we will not attempt to analyze recursive types, hence no > | SMu or SRec constructor above. > | > | With the analysis accepting sum types we will be able to analyze > | functions with sum types as parameters, as a trivial example: > | > | fromMaybe2 x y = case x of > | Just v -> v > | Nothing -> y > | > | You would get a demand signature like: > | > | Str=Dmdtype ), ("Nothing", <>)],U> > | > | Which says that the function is strict in its first argument and that > | if the value is a 'Just' then its field is used strictly, if the value > | is a 'Nothing' then there is no further demand (a nullary product). > | > | For those with more experience in these matter, does this seem to be a > | sensible approach? > | > | Thanks in advance for any insight, > | > | Jose > | > | > | [1]: Those of you who saw my Haskell Symposium talk on implicit > | parallelism last year might remember that we will need the analysis to > | work on recursive types in order to automatically generate parallel > | strategies, but that's for later (I've spoken with Ilya Sergey about > | working on that). > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha > | skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- > | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cf731333e0c5d45f3 > | 298408d33755dc98%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=hWHFSUVrr > | ZQqTPeQsFMQVlveHgV5ozx6%2bdpsylRIwhg%3d From mail at joachim-breitner.de Sun Feb 21 23:26:13 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 22 Feb 2016 00:26:13 +0100 Subject: Generalising the demand analysis to sum types In-Reply-To: References: <5ef58ac4619940608835ec3662591316@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <1456097173.10907.5.camel@joachim-breitner.de> Hi, Am Samstag, den 20.02.2016, 18:01 -0500 schrieb Jos? Manuel Calder?n Trilla: > The way I see it, the information would allow us to automatically > unbox the arguments to constructors in sum types. Well, unboxed sums asides, how can you unbox the argument to Just? "Just" necessary takes a boxed argument... Can you show some example code of a function that is strict in the way you envision, and show how the worker and the wrapper look like? > Combining this with the unboxed sums work, the idea is to be able to > not only unbox the sum, but the fields of a constructor when possible, > removing as many indirections as possible. Yes, with unboxed sums there might be something to gain, i.e. replacing "Maybe Int" with "(# Int# | (##) #)" or whatever. But even then it is not clear: The function likely scrutinizes the argument, i.e. we have a branch, both before and after the transformation. But the wrapper _also_ needs to case-analyze the argument, to create the unboxed sum variant... and I worry that the wrapper will be optimized away very often. But a good example might convince me :-) Greetings, Joachim -- Joachim ?nomeata? Breitner ? mail at joachim-breitner.de ? https://www.joachim-breitner.de/ ? XMPP: nomeata at joachim-breitner.de?? OpenPGP-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 Feb 22 11:54:22 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 22 Feb 2016 11:54:22 +0000 Subject: "Excuse me, I think this i my stop..." - Resigning from the Platform In-Reply-To: References: Message-ID: <19e208fbbc0e4ba0b90c2ee27d606ea7@DB4PR30MB030.064d.mgd.msft.net> Mark I?m really sorry to see you go. You have played a key leadership role, and have given us a lot of your most precious and inelastic commodity, your own time. Thank you! Simon From: haskell-platform-bounces at projects.haskell.org [mailto:haskell-platform-bounces at projects.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 simonpj at microsoft.com Mon Feb 22 16:15:09 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 22 Feb 2016 16:15:09 +0000 Subject: "Excuse me, I think this i my stop..." - Resigning from the Platform References: Message-ID: Ha ha. You may wonder why I?m replying to a message from four months ago. Mark?s message was written on 13 Oct 2015, and was delivered to me then. And I replied the same day, at rather greater length than below. But then I received it again, yesterday. The very same message! I have no idea why. Email is a Mysterious Medium. Anyway, thanking Mark twice is something he deserves anyway ?. Simon From: Simon Peyton Jones Sent: 22 February 2016 11:54 To: 'Mark Lentczner' Cc: haskell-platform at projects.haskell.org; Haskell Libraries ; ghc-devs at haskell.org Subject: RE: "Excuse me, I think this i my stop..." - Resigning from the Platform Mark I?m really sorry to see you go. You have played a key leadership role, and have given us a lot of your most precious and inelastic commodity, your own time. Thank you! Simon From: haskell-platform-bounces at projects.haskell.org [mailto:haskell-platform-bounces at projects.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 allbery.b at gmail.com Mon Feb 22 16:25:10 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 22 Feb 2016 11:25:10 -0500 Subject: "Excuse me, I think this i my stop..." - Resigning from the Platform In-Reply-To: References: Message-ID: On Mon, Feb 22, 2016 at 11:15 AM, Simon Peyton Jones wrote: > But then I received it again, yesterday. The very same message! I have > no idea why. Email is a Mysterious Medium. I think they restarted the mailing list server; I got that message and a handful of other messages, which apparently never got cleared from the mail queue or something. And IIRC shortly before the resends, someone in #haskell was asking if there were problems with the mailing lists. (this kind of stuff is why I got out of the business of running mail servers) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From juhpetersen at gmail.com Tue Feb 23 10:22:36 2016 From: juhpetersen at gmail.com (Jens Petersen) Date: Tue, 23 Feb 2016 19:22:36 +0900 Subject: [ANNOUNCE] GHC 8.0.1 release candidate 2 In-Reply-To: <8737t49yof.fsf@smart-cactus.org> References: <8737t49yof.fsf@smart-cactus.org> Message-ID: On 8 February 2016 at 03:13, Ben Gamari wrote: > http://downloads.haskell.org/~ghc/8.0.1-rc2/ Thank you for RC2. I finally built ghc-8.0.0 for Fedora Rawhide (quick build): https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.0.1 (perf build is still ongoing). One minor thing I noticed is that docdir seems have changed RC2 to be versioned. ie the LICENSE files for the included libraries now get installed under "/usr/share/doc/ghc-/html/libraries/*/" rather than "/usr/share/doc/ghc/html/libraries/*/" before. I managed to work around that by configuring with --docdir=/usr/share/doc but it took me by surprise. I should open a ticket I guess... Jens From alan.zimm at gmail.com Tue Feb 23 13:35:03 2016 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Tue, 23 Feb 2016 15:35:03 +0200 Subject: ORF and renamer Message-ID: I am working on updating HaRe for GHC 8.0.1, and have hit an issue with the following file --------------------------- module Field1 where --Rename field name 'pointx' to 'pointx1' data Point = Pt {pointx, pointy :: Float} absPoint :: Point -> Float absPoint p = sqrt (pointx p * pointx p + pointy p * pointy p) -------------------------- It seems that after the renamer, each of the three instances of `pointx` has a different `nameUnique` value. Is this because the final resolution is now done during type checking? If so it makes the RenamedSource much harder to work with. Alan From adam at well-typed.com Tue Feb 23 14:20:06 2016 From: adam at well-typed.com (Adam Gundry) Date: Tue, 23 Feb 2016 14:20:06 +0000 Subject: ORF and renamer In-Reply-To: References: Message-ID: <56CC6A96.4050104@well-typed.com> Hi Alan, I certainly made a few changes to the renamer as part of the ORF work, but I wouldn't expect them to cause the behaviour you describe. Name resolution for ambiguous record selectors is deferred to the typechecker when the DuplicateRecordFields extension is enabled, but unambiguous selectors (as in your example) are resolved by the renamer. Moreover, I didn't touch anything to do with uniques. The record selector will be in scope once, with a single Name containing a single Unique. Unfortunately, I can't reproduce the behaviour you describe with: ghc-8.0.0.20160204 Field1.hs -ddump-rn-trace -dppr-debug Can you describe in more detail how to reproduce the problem? All the best, Adam On 23/02/16 13:35, Alan & Kim Zimmerman wrote: > I am working on updating HaRe for GHC 8.0.1, and have hit an issue > with the following file > > --------------------------- > module Field1 where > > --Rename field name 'pointx' to 'pointx1' > > data Point = Pt {pointx, pointy :: Float} > > absPoint :: Point -> Float > absPoint p = sqrt (pointx p * pointx p + > pointy p * pointy p) > -------------------------- > > It seems that after the renamer, each of the three instances of > `pointx` has a different `nameUnique` value. > > Is this because the final resolution is now done during type checking? > If so it makes the RenamedSource much harder to work with. > > Alan -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From alan.zimm at gmail.com Tue Feb 23 18:29:39 2016 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Tue, 23 Feb 2016 20:29:39 +0200 Subject: ORF and renamer In-Reply-To: <56CC6A96.4050104@well-typed.com> References: <56CC6A96.4050104@well-typed.com> Message-ID: Hi Adam Thanks for the response. My initial mail was more of a sanity check to see if anything had in fact changed, as I saw that the ambiguous case is pushed to the type checker. I wanted to confirm the unambiguous case treatment. I will try to make a clearer description of what I see/am doing. Alan On Tue, Feb 23, 2016 at 4:20 PM, Adam Gundry wrote: > Hi Alan, > > I certainly made a few changes to the renamer as part of the ORF work, > but I wouldn't expect them to cause the behaviour you describe. Name > resolution for ambiguous record selectors is deferred to the typechecker > when the DuplicateRecordFields extension is enabled, but unambiguous > selectors (as in your example) are resolved by the renamer. Moreover, I > didn't touch anything to do with uniques. The record selector will be in > scope once, with a single Name containing a single Unique. > > Unfortunately, I can't reproduce the behaviour you describe with: > > ghc-8.0.0.20160204 Field1.hs -ddump-rn-trace -dppr-debug > > Can you describe in more detail how to reproduce the problem? > > All the best, > > Adam > > > On 23/02/16 13:35, Alan & Kim Zimmerman wrote: >> I am working on updating HaRe for GHC 8.0.1, and have hit an issue >> with the following file >> >> --------------------------- >> module Field1 where >> >> --Rename field name 'pointx' to 'pointx1' >> >> data Point = Pt {pointx, pointy :: Float} >> >> absPoint :: Point -> Float >> absPoint p = sqrt (pointx p * pointx p + >> pointy p * pointy p) >> -------------------------- >> >> It seems that after the renamer, each of the three instances of >> `pointx` has a different `nameUnique` value. >> >> Is this because the final resolution is now done during type checking? >> If so it makes the RenamedSource much harder to work with. >> >> Alan > > > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From alan.zimm at gmail.com Tue Feb 23 20:14:01 2016 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Tue, 23 Feb 2016 22:14:01 +0200 Subject: ORF and renamer In-Reply-To: References: <56CC6A96.4050104@well-typed.com> Message-ID: Adam FYI, using https://github.com/alanz/ghc-dump-tree/tree/debug-name I can see that I have a bug elsewhere in my code. The output is http://lpaste.net/8427907315830620160, which includes the nameUnique for each Name in the RenamedSource. e.g. http://lpaste.net/8427907315830620160#line267 Regards Alan On Tue, Feb 23, 2016 at 8:29 PM, Alan & Kim Zimmerman wrote: > Hi Adam > > Thanks for the response. My initial mail was more of a sanity check to > see if anything had in fact changed, as I saw that the ambiguous case > is pushed to the type checker. I wanted to confirm the unambiguous > case treatment. > > I will try to make a clearer description of what I see/am doing. > > Alan > > > On Tue, Feb 23, 2016 at 4:20 PM, Adam Gundry wrote: >> Hi Alan, >> >> I certainly made a few changes to the renamer as part of the ORF work, >> but I wouldn't expect them to cause the behaviour you describe. Name >> resolution for ambiguous record selectors is deferred to the typechecker >> when the DuplicateRecordFields extension is enabled, but unambiguous >> selectors (as in your example) are resolved by the renamer. Moreover, I >> didn't touch anything to do with uniques. The record selector will be in >> scope once, with a single Name containing a single Unique. >> >> Unfortunately, I can't reproduce the behaviour you describe with: >> >> ghc-8.0.0.20160204 Field1.hs -ddump-rn-trace -dppr-debug >> >> Can you describe in more detail how to reproduce the problem? >> >> All the best, >> >> Adam >> >> >> On 23/02/16 13:35, Alan & Kim Zimmerman wrote: >>> I am working on updating HaRe for GHC 8.0.1, and have hit an issue >>> with the following file >>> >>> --------------------------- >>> module Field1 where >>> >>> --Rename field name 'pointx' to 'pointx1' >>> >>> data Point = Pt {pointx, pointy :: Float} >>> >>> absPoint :: Point -> Float >>> absPoint p = sqrt (pointx p * pointx p + >>> pointy p * pointy p) >>> -------------------------- >>> >>> It seems that after the renamer, each of the three instances of >>> `pointx` has a different `nameUnique` value. >>> >>> Is this because the final resolution is now done during type checking? >>> If so it makes the RenamedSource much harder to work with. >>> >>> Alan >> >> >> >> -- >> Adam Gundry, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com/ >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From thomasmiedema at gmail.com Wed Feb 24 14:30:29 2016 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Wed, 24 Feb 2016 15:30:29 +0100 Subject: Patches/proposals waiting for review Message-ID: Hi Simon, the following issues are waiting for your review: * https://phabricator.haskell.org/D1762 "Fix #11348 handle instance dependencies" by Alexander Vieth * https://phabricator.haskell.org/D1896 "Improve printing of pattern synonym types" by Rik Steenkamp * https://ghc.haskell.org/trac/ghc/wiki/ShorterImportSyntax by Anthony Cowley Maybe others, they should show up under "Blocking Others" when you go to https://phabricator.haskell.org/ Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From chak at justtesting.org Thu Feb 25 02:07:19 2016 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Thu, 25 Feb 2016 13:07:19 +1100 Subject: New type of ($) operator in GHC 8.0 is problematic In-Reply-To: <1455764544.2889103.524482378.1C9DA511@webmail.messagingengine.com> References: <87egcg93zn.fsf@smart-cactus.org> <1455381609.2134.16.camel@gmail.com> <87si0u6y9h.fsf@smart-cactus.org> <8737st6iyg.fsf@smart-cactus.org> <98EE8A62-8397-4D21-ABB4-63D4604D7062@cis.upenn.edu> <9723F5A2-8FA7-4389-AE55-B46481748216@justtesting.org> <1455764544.2889103.524482378.1C9DA511@webmail.messagingengine.com> Message-ID: Two notable differences between Racket and the situation in Haskell is that (1) Racket has a full blown IDE to support the staged languages and (2) AFIK any Racket program in a simpler language is still a valid Racket program in a more advanced language. (The latter wouldn?t be the case with, e.g., a Prelude omitting type classes as you need to introduce new names ?to avoid overloading? that are no longer valid in the full Prelude.) Manuel > Eric Seidel : > > On Wed, Feb 17, 2016, at 08:09, Christopher Allen wrote: >> I have tried a beginner's Prelude with people. I don't have a lot of data >> because it was clearly a failure early on so I bailed them out into the >> usual thing. It's just not worth it and it deprives them of the >> preparedness to go write real Haskell code. That's not something I'm >> willing to give up just so I can teach _less_. > > Chris, have you written about your experiences teaching with a > beginner's Prelude? I'd be quite interested to read about it, as (1) it > seems like a natural thing to do and (2) the Racket folks seem to have > had good success with their staged teaching languages. > > In particular, I'm curious if your experience is in the context of > teaching people with no experience programming at all, vs programming > experience but no Haskell (or generally FP) experience. The Racket "How > to Design Programs" curriculum seems very much geared towards absolute > beginners, and that could be a relevant distinction. > > Thanks! > Eric > _______________________________________________ > 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 Feb 25 02:58:14 2016 From: david.feuer at gmail.com (David Feuer) Date: Wed, 24 Feb 2016 21:58:14 -0500 Subject: Pattern synonym thoughts Message-ID: There are two features I think would make pattern synonyms even nicer: 1. If a pattern synonym is defined in the same module as one of the type constructors in the type of thing it matches, then it should be possible to export it "attached" to one or more of those constructors (normally but not necessarily the outermost one g. An example of how this might look: module Foo (A (.., S)) data A = X | Y pattern S = X Someone writing a module importing Foo wouldn't even need to know that S was a pattern synonym--they'd just import Foo (A (..)) and be done with it. The (.., S) here means "export all A's constructors, along with the pattern synonym S". 2. Pattern synonym groups This vague idea attacks a long-standing efficiency concern. It's not fully formed in my mind, but I'd love to be able to write groups of pattern synonyms that all use a *guaranteed shared* computed view of the underlying structure. Once the first synonym in the group is encountered, the view is calculated and held until the pattern match completes or the last synonym in the group is rejected. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasmiedema at gmail.com Thu Feb 25 03:11:15 2016 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Thu, 25 Feb 2016 04:11:15 +0100 Subject: Pattern synonym thoughts In-Reply-To: References: Message-ID: > > 1. If a pattern synonym is defined in the same module as one of the type > constructors in the type of thing it matches, then it should be possible to > export it "attached" to one or more of those constructors > See https://ghc.haskell.org/trac/ghc/ticket/10653 Already implemented by Matthew Pickering, and will be in GHC 8.0. I don't know about your second issue. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Thu Feb 25 17:09:14 2016 From: ben at well-typed.com (Ben Gamari) Date: Thu, 25 Feb 2016 18:09:14 +0100 Subject: [ANNOUNCE] GHC 8.0.1 release candidate 2 In-Reply-To: References: <8737t49yof.fsf@smart-cactus.org> Message-ID: <87bn741zut.fsf@smart-cactus.org> Jens Petersen writes: > On 8 February 2016 at 03:13, Ben Gamari wrote: >> http://downloads.haskell.org/~ghc/8.0.1-rc2/ > > Thank you for RC2. > I'm happy to help. Sorry about the delayed response Jens; I'm still catching up after some downtime due to sickness earlier this week. > I finally built ghc-8.0.0 for Fedora Rawhide (quick build): > https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.0.1 > (perf build is still ongoing). > > One minor thing I noticed is that docdir seems have changed RC2 to be versioned. > ie the LICENSE files for the included libraries now get installed under > "/usr/share/doc/ghc-/html/libraries/*/" rather than > "/usr/share/doc/ghc/html/libraries/*/" before. > I managed to work around that by configuring with > --docdir=/usr/share/doc but it took me by surprise. > This was an intentional change; see #11354. I'll make sure it is mentioned in the next release candidate announcement. Thanks for mentioning 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 omeragacan at gmail.com Sat Feb 27 03:12:48 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Fri, 26 Feb 2016 22:12:48 -0500 Subject: Change in demand analysis results between 7.10.2 and RC1 (not fixed in RC2 and HEAD) Message-ID: Hi all, While working on demand analyzer today we realized that there has been some changes in demand analysis results between GHC 7.10.2 and 8.0-rc2. Here's a minimal example: {-# LANGUAGE BangPatterns #-} module Main where data Prod a = Prod !a !a addProd :: Prod Int -> Prod Int -> Prod Int addProd (Prod i1 i2) (Prod i3 i4) = Prod i1 (i2 + i4) main = return () Compiled with 7.10.2: addProd :: Prod Int -> Prod Int -> Prod Int [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType m, ...}}}}] addProd = \ (ds_dzH :: Prod Int) (ds1_dzI :: Prod Int) -> case ds_dzH of _ [Occ=Dead] { Prod i1_an2 i2_an3 -> case i2_an3 of _ [Occ=Dead] { GHC.Types.I# x_s2B4 -> case ds1_dzI of _ [Occ=Dead] { Prod i3_an4 i4_an5 -> case i4_an5 of _ [Occ=Dead] { GHC.Types.I# y_s2B7 -> Main.Prod @ Int i1_an2 (GHC.Types.I# (GHC.Prim.+# x_s2B4 y_s2B7)) } } } } Compiled with 8.0-rc2: -- RHS size: {terms: 20, types: 17, coercions: 0} addProd :: Prod Int -> Prod Int -> Prod Int [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType m, ...}}}}] addProd = \ (ds_dQL :: Prod Int) (ds1_dQM :: Prod Int) -> case ds_dQL of _ [Occ=Dead] { Prod i1_avS i2_avT -> case i2_avT of _ [Occ=Dead] { GHC.Types.I# x_s1vO -> case ds1_dQM of _ [Occ=Dead] { Prod i3_avU i4_avV -> case i4_avV of _ [Occ=Dead] { GHC.Types.I# y_s1vR -> Main.Prod @ Int i1_avS (GHC.Types.I# (GHC.Prim.+# x_s1vO y_s1vR)) } } } } To highlight the difference, GHC 7.10.2: GHC 8.0-rc2: (NOTE: Also tried with HEAD and rc1 just now, the results are the same as rc2) The demand put on the second argument is more strict in GHC 7.10. Was that an intentional change? Any ideas on why this might be happening? In our case, we prefer the result in 7.10.2 of course, because that's a more precise demand and it gives us more opportunities for optimizations. But I guess this could potentially reveal itself in some other situations and make some programs slower? Any ideas? Thanks.. From mail at joachim-breitner.de Sat Feb 27 08:49:25 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 27 Feb 2016 09:49:25 +0100 Subject: Change in demand analysis results between 7.10.2 and RC1 (not fixed in RC2 and HEAD) In-Reply-To: References: Message-ID: <1456562965.1605.1.camel@joachim-breitner.de> Hi, Am Freitag, den 26.02.2016, 22:12 -0500 schrieb ?mer Sinan A?acan: > While working on demand analyzer today we realized that there has > been some changes in demand analysis results between GHC 7.10.2 and > 8.0-rc2.? a quick git log highlights this commit, as it relates to strict data constructors: 0696fc6d4de28cb589f6c751b8491911a5baf774 commit 0696fc6d4de28cb589f6c751b8491911a5baf774 Author: Simon Peyton Jones Date:???Fri Jun 26 11:40:01 2015 +0100 ????Improve CPR behavior for strict constructors ???? ????When working on Trac #10482 I noticed that we could give constructor ????arguments the CPR property if they are use strictly. ???? ????This is documented carefully in ????????Note [CPR in a product case alternative] ????and also ????????Note [Initial CPR for strict binders] ???? ????There are a bunch of intersting examples in ????????Note [CPR examples] ????which I have added to the test suite as T10482a. ???? ????I also added a test for #10482 itself. I did not investigate whether this could actually have effected? this change. Greetings, Joachim ? How do you recognize a regular xkcd reader? ? He uses effect as an verb. https://xkcd.com/326/ --? -- Joachim ?nomeata? Breitner ? mail at joachim-breitner.de ? https://www.joachim-breitner.de/ ? XMPP: nomeata at joachim-breitner.de?? OpenPGP-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 well-typed.com Sat Feb 27 13:57:14 2016 From: ben at well-typed.com (Ben Gamari) Date: Sat, 27 Feb 2016 14:57:14 +0100 Subject: GHC 8.0.1 status Message-ID: <87wppqz26d.fsf@smart-cactus.org> tl;dr. Stabilizing the ghc-8.0 is taking a bit longer than was anticipated. The release schedule is being pushed back a bit. Hello everyone, As you likely know we are currently in the depths of the 8.0 release. In fact, under more ideal circumstances I would probably be cutting another release candidate right now instead of writing this email, in preparation for a final release next week or so. However, our world is far from ideal as evidenced by the number [1] of significant bugs present on the 8.0 branch. This isn't altogether unexpected; we knew we were taking a bit of a risk in merging so many high-impact patches in one release. However, we thought that given a longer-than-usual period between first-candidate and the final release, we'd have enough time to smooth out the wrinkles. Sadly, this has taken a bit longer than we anticipated. Of course, the last thing we want is to push a known buggy release out the door. Consequently, we won't be delivering the 8.0.1 release next week as originally planned. Instead, we'll be pushing the release back by about three weeks. This will give developers a bit more breathing room in which to work out the remaining issues. Hopefully in a few weeks the tree will be in such a state that we can push out yet another candidate which, with luck, will be the last before the release. If you'd like to expedite the process (and have fun in the process), you could do worse than to having a look at Trac [1], choosing a bug of your liking, and trying your hand at solving it. Thanks to everyone who has contributed to this effort thusfar. If you have any questions about the release process or how you can help, don't hesistate to ask. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From christiaan.baaij at gmail.com Sat Feb 27 22:04:40 2016 From: christiaan.baaij at gmail.com (Christiaan Baaij) Date: Sat, 27 Feb 2016 23:04:40 +0100 Subject: GHC 8.0.1 status In-Reply-To: <87wppqz26d.fsf@smart-cactus.org> References: <87wppqz26d.fsf@smart-cactus.org> Message-ID: Given that I was working on at least once package ( https://github.com/goldfirere/singletons/pull/142) which gave panics on GHC8-rc2, couldn't we get at least an GHC8-rc3 before doing an 8.0.1 release in 3 weeks? On 27 February 2016 at 14:57, Ben Gamari wrote: > tl;dr. Stabilizing the ghc-8.0 is taking a bit longer than was anticipated. > The release schedule is being pushed back a bit. > > > Hello everyone, > > As you likely know we are currently in the depths of the 8.0 release. In > fact, under more ideal circumstances I would probably be cutting another > release candidate right now instead of writing this email, in > preparation for a final release next week or so. > > However, our world is far from ideal as evidenced by the number > [1] of significant bugs present on the 8.0 branch. This isn't altogether > unexpected; we knew we were taking a bit of a risk in merging so many > high-impact patches in one release. However, we thought that given a > longer-than-usual period between first-candidate and the final release, > we'd have enough time to smooth out the wrinkles. Sadly, this has taken > a bit longer than we anticipated. > > Of course, the last thing we want is to push a known buggy release out > the door. Consequently, we won't be delivering the 8.0.1 release next > week as originally planned. Instead, we'll be pushing the release back > by about three weeks. This will give developers a bit more breathing > room in which to work out the remaining issues. Hopefully in a few weeks > the tree will be in such a state that we can push out yet another > candidate which, with luck, will be the last before the release. > > If you'd like to expedite the process (and have fun in the process), you > could do worse than to having a look at Trac [1], choosing a bug of your > liking, and trying your hand at solving it. > > Thanks to everyone who has contributed to this effort thusfar. > If you have any questions about the release process or how you can help, > don't hesistate to ask. > > Cheers, > > - Ben > > > [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1 > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Sat Feb 27 22:58:42 2016 From: ben at well-typed.com (Ben Gamari) Date: Sat, 27 Feb 2016 23:58:42 +0100 Subject: GHC 8.0.1 status In-Reply-To: References: <87wppqz26d.fsf@smart-cactus.org> Message-ID: <87si0dzrod.fsf@smart-cactus.org> Christiaan Baaij writes: > Given that I was working on at least once package ( > https://github.com/goldfirere/singletons/pull/142) which gave panics on > GHC8-rc2, couldn't we get at least an GHC8-rc3 before doing an 8.0.1 > release in 3 weeks? As I said in the original message (and several times prior), > Hopefully in a few weeks the tree will be in such a state that we can > push out yet another candidate which, with luck, will be the last > before the release. that is, there will be *at least* one more release candidate before the final release. Fear not; we will not be pushing out 8.0.1 until we are convinced it has been sufficiently tested. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From omeragacan at gmail.com Mon Feb 29 03:16:09 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Sun, 28 Feb 2016 22:16:09 -0500 Subject: CoreLint check for case with no alts Message-ID: Hi all, CoreLint has a check that, when seeing a case expression with empty list of alternatives, checks whether the scrutinee is bottom. This "bottom-ness" check is, however, very simple and returning many false negatives. For example, when it sees a case expression, all it does is: go _ (Case _ _ _ alts) = null alts Which is just too simple for some cases. (it could check if all the RHSs are bottom, or if the scrutinee is bottom etc.) I guess this makes sense, since it's OK to generate unreachable code, but it's not OK to not generate a code in a reachable path. But in my case this is becoming problem as it's rejecting my seemingly valid program. One of the relevant parts in my code is this: case ww_s4C3 of ww_X4Fb { (#_||#) ww_s4Ce -> case case ww_s4Ce of ww_s4F1 { (# ww_s4F2, ww_s4F3 #) -> lvl_s4F4 ww_s4F3 ww_s4F2 } of wild_00 { -- empty }; lvl_s4F4 :: Int# -> String -> Var [LclId, Arity=2, Str=DmdType (args: ) (res: x)] lvl_s4F4 = \ (ww_s4F3 :: Int#) (ww_s4F2 :: String) -> lvl_s3V4 (TyVar ww_s4F2 ww_s4F3) lvl_s3V4 :: Var -> Var [LclId, Arity=1, CallArity=1, Str=DmdType (args: ) (res: x)] lvl_s3V4 = \ (i_a1vO :: Var) -> lvl_s4EZ i_a1vO lvl_s4EZ :: Var -> Var [LclId, Arity=1, Str=DmdType (args: ) (res: x)] lvl_s4EZ = \ (i_a1vO :: Var) -> error ... The scrutinee part of the case expression in the alternative is clearly bottom, but this expression is rejected by the linter. One easy solution is to implement a more precise test and use it in linter. But I thought maybe the current implementation is deliberately so. Maybe the code generator doesn't support that type of code etc. so I wanted to ask: Is there a restriction on what kind empty case expressions are supported by the code generator or can I just improve the lint check and assume that the code will be handled by the code generator correctly? Thanks. From omeragacan at gmail.com Mon Feb 29 03:22:38 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Sun, 28 Feb 2016 22:22:38 -0500 Subject: Change in demand analysis results between 7.10.2 and RC1 (not fixed in RC2 and HEAD) In-Reply-To: <1456562965.1605.1.camel@joachim-breitner.de> References: <1456562965.1605.1.camel@joachim-breitner.de> Message-ID: Thanks, but that patch looks like for CPR. In our case demands are changed, so I don't see how that's related. Am I missing anything in that patch? 2016-02-27 3:49 GMT-05:00 Joachim Breitner : > Hi, > Am Freitag, den 26.02.2016, 22:12 -0500 schrieb ?mer Sinan A?acan: >> While working on demand analyzer today we realized that there has >> been some changes in demand analysis results between GHC 7.10.2 and >> 8.0-rc2. > > > a quick git log highlights this commit, as it relates to strict data > constructors: 0696fc6d4de28cb589f6c751b8491911a5baf774 > > commit 0696fc6d4de28cb589f6c751b8491911a5baf774 > Author: Simon Peyton Jones > Date: Fri Jun 26 11:40:01 2015 +0100 > > Improve CPR behavior for strict constructors > > When working on Trac #10482 I noticed that we could give constructor > arguments the CPR property if they are use strictly. > > This is documented carefully in > Note [CPR in a product case alternative] > and also > Note [Initial CPR for strict binders] > > There are a bunch of intersting examples in > Note [CPR examples] > which I have added to the test suite as T10482a. > > I also added a test for #10482 itself. > > I did not investigate whether this could actually have effected? this > change. > > Greetings, > Joachim > > ? How do you recognize a regular xkcd reader? > He uses effect as an verb. https://xkcd.com/326/ > > -- > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? https://www.joachim-breitner.de/ > XMPP: nomeata at joachim-breitner.de ? OpenPGP-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 juhpetersen at gmail.com Mon Feb 29 08:50:37 2016 From: juhpetersen at gmail.com (Jens Petersen) Date: Mon, 29 Feb 2016 17:50:37 +0900 Subject: [ANNOUNCE] GHC 8.0.1 release candidate 2 In-Reply-To: <87bn741zut.fsf@smart-cactus.org> References: <8737t49yof.fsf@smart-cactus.org> <87bn741zut.fsf@smart-cactus.org> Message-ID: On 26 February 2016 at 02:09, Ben Gamari wrote: >> Thank you for RC2. > I'm happy to help. I think you're doing a great job. >> I finally built ghc-8.0.0 for Fedora Rawhide (quick build): >> https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.0.1 >> (perf build is still ongoing). Fedora perf builds are done now btw. >> One minor thing I noticed is that docdir seems have changed RC2 to be versioned. >> ie the LICENSE files for the included libraries now get installed under >> "/usr/share/doc/ghc-/html/libraries/*/" rather than >> "/usr/share/doc/ghc/html/libraries/*/" before. >> I managed to work around that by configuring with >> --docdir=/usr/share/doc but it took me by surprise. >> > This was an intentional change; see #11354. I'll make sure it is > mentioned in the next release candidate announcement. Thanks for > mentioning this. https://ghc.haskell.org/trac/ghc/ticket/11354 I see, thanks. I added a comment, since 'configure --help' still says the default is unversioned, and I opened a new ticket https://ghc.haskell.org/trac/ghc/ticket/11659 for this. Thanks, Jens From simonpj at microsoft.com Mon Feb 29 10:10:38 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 29 Feb 2016 10:10:38 +0000 Subject: Change in demand analysis results between 7.10.2 and RC1 (not fixed in RC2 and HEAD) In-Reply-To: References: Message-ID: See Note [Add demands for strict constructors] in DmdAnal, esp the bit that says If the argument is not used at all in the alternative (i.e. it is Absent), then *don't* add a 'seqDmd'. If we do, it makes it look used and hence it'll be passed to the worker when it doesn't need to be. Hence the isAbsDmd test in addDataConStrictness. Why do you say | In our case, we prefer the result in 7.10.2 of course, because that's a | more precise demand and it gives us more opportunities for | optimizations. But I guess this could potentially reveal itself in some What optimisations do you have in mind? Simon | -----Original Message----- | From: ?mer Sinan A?acan [mailto:omeragacan at gmail.com] | Sent: 27 February 2016 03:13 | To: ghc-devs ; Simon Peyton Jones | | Cc: Jose Calderon | Subject: Change in demand analysis results between 7.10.2 and RC1 (not | fixed in RC2 and HEAD) | | Hi all, | | While working on demand analyzer today we realized that there has been | some changes in demand analysis results between GHC 7.10.2 and 8.0-rc2. | Here's a minimal example: | | {-# LANGUAGE BangPatterns #-} | | module Main where | | data Prod a = Prod !a !a | | addProd :: Prod Int -> Prod Int -> Prod Int | addProd (Prod i1 i2) (Prod i3 i4) = Prod i1 (i2 + i4) | | main = return () | | Compiled with 7.10.2: | | addProd :: Prod Int -> Prod Int -> Prod Int | [GblId, | Arity=2, | Caf=NoCafRefs, | Str=DmdType m, | ...}}}}] | addProd = | \ (ds_dzH :: Prod Int) (ds1_dzI :: Prod Int) -> | case ds_dzH of _ [Occ=Dead] { Prod i1_an2 i2_an3 -> | case i2_an3 of _ [Occ=Dead] { GHC.Types.I# x_s2B4 -> | case ds1_dzI of _ [Occ=Dead] { Prod i3_an4 i4_an5 -> | case i4_an5 of _ [Occ=Dead] { GHC.Types.I# y_s2B7 -> | | https://na01.safelinks.protection.outlook.com/?url=Main.Prod&data=01%7c | 01%7csimonpj%40064d.mgd.microsoft.com%7c7b5d6e60d31348506eb108d33f23f6b | f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=NfCiyeSjPwsWage0KlgkMkQR | jWVexsdlCq0Dla%2f1I10%3d @ Int i1_an2 (GHC.Types.I# (GHC.Prim.+# x_s2B4 | y_s2B7)) | } | } | } | } | | Compiled with 8.0-rc2: | | -- RHS size: {terms: 20, types: 17, coercions: 0} | addProd :: Prod Int -> Prod Int -> Prod Int | [GblId, | Arity=2, | Caf=NoCafRefs, | Str=DmdType m, | ...}}}}] | addProd = | \ (ds_dQL :: Prod Int) (ds1_dQM :: Prod Int) -> | case ds_dQL of _ [Occ=Dead] { Prod i1_avS i2_avT -> | case i2_avT of _ [Occ=Dead] { GHC.Types.I# x_s1vO -> | case ds1_dQM of _ [Occ=Dead] { Prod i3_avU i4_avV -> | case i4_avV of _ [Occ=Dead] { GHC.Types.I# y_s1vR -> | | https://na01.safelinks.protection.outlook.com/?url=Main.Prod&data=01%7c | 01%7csimonpj%40064d.mgd.microsoft.com%7c7b5d6e60d31348506eb108d33f23f6b | f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=NfCiyeSjPwsWage0KlgkMkQR | jWVexsdlCq0Dla%2f1I10%3d @ Int i1_avS (GHC.Types.I# (GHC.Prim.+# x_s1vO | y_s1vR)) | } | } | } | } | | To highlight the difference, | | GHC 7.10.2: | GHC 8.0-rc2: | | (NOTE: Also tried with HEAD and rc1 just now, the results are the same | as rc2) | | The demand put on the second argument is more strict in GHC 7.10. Was | that an intentional change? Any ideas on why this might be happening? | | In our case, we prefer the result in 7.10.2 of course, because that's a | more precise demand and it gives us more opportunities for | optimizations. But I guess this could potentially reveal itself in some | other situations and make some programs slower? Any ideas? | | Thanks.. From simonpj at microsoft.com Mon Feb 29 11:32:10 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 29 Feb 2016 11:32:10 +0000 Subject: CoreLint check for case with no alts In-Reply-To: References: Message-ID: <62193e132f15422c93d6154ed9a755da@DB4PR30MB030.064d.mgd.msft.net> | I wanted to ask: Is there a restriction on what kind empty case | expressions are supported by the code generator or can I just improve | the lint check and assume that the code will be handled by the code | generator correctly? I believe the latter. See CoreToStg line 364. So feel free to make Lint cleverer; make sure you add a Note. But if it /needs/ to be cleverer, that suggests that the simplifier should be cleverer instead, and should simplify the code so that even a dumb Core Lint has no trouble. In your example why didn't the simplifier do case-of-case? I suppose that this might be after some pass and before a simplifier run. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of ?mer | Sinan Agacan | Sent: 29 February 2016 03:16 | To: ghc-devs | Subject: CoreLint check for case with no alts | | Hi all, | | CoreLint has a check that, when seeing a case expression with empty | list of alternatives, checks whether the scrutinee is bottom. This | "bottom-ness" check is, however, very simple and returning many false | negatives. For example, when it sees a case expression, all it does is: | | go _ (Case _ _ _ alts) = null alts | | Which is just too simple for some cases. (it could check if all the | RHSs are bottom, or if the scrutinee is bottom etc.) | | I guess this makes sense, since it's OK to generate unreachable code, | but it's not OK to not generate a code in a reachable path. | | But in my case this is becoming problem as it's rejecting my seemingly | valid program. One of the relevant parts in my code is this: | | case ww_s4C3 of ww_X4Fb { | (#_||#) ww_s4Ce -> | case case ww_s4Ce of ww_s4F1 { (# ww_s4F2, ww_s4F3 #) -> | lvl_s4F4 ww_s4F3 ww_s4F2 | } | of wild_00 { | -- empty | }; | | lvl_s4F4 :: Int# -> String -> Var | [LclId, Arity=2, Str=DmdType (args: ) (res: x)] | lvl_s4F4 = | \ (ww_s4F3 :: Int#) (ww_s4F2 :: String) -> | lvl_s3V4 (TyVar ww_s4F2 ww_s4F3) | | lvl_s3V4 :: Var -> Var | [LclId, Arity=1, CallArity=1, Str=DmdType (args: ) (res: x)] | lvl_s3V4 = \ (i_a1vO :: Var) -> lvl_s4EZ i_a1vO | | lvl_s4EZ :: Var -> Var | [LclId, Arity=1, Str=DmdType (args: ) (res: x)] | lvl_s4EZ = \ (i_a1vO :: Var) -> error ... | | The scrutinee part of the case expression in the alternative is clearly | bottom, but this expression is rejected by the linter. | | One easy solution is to implement a more precise test and use it in | linter. But I thought maybe the current implementation is deliberately | so. Maybe the code generator doesn't support that type of code etc. so | I wanted to ask: Is there a restriction on what kind empty case | expressions are supported by the code generator or can I just improve | the lint check and assume that the code will be handled by the code | generator correctly? | | Thanks. | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha | skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce621b9bcb2774ff8 | 522208d340b6c5a7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=cIiMVTgiH | ibh0SNksSZGLK75bZBgb3HA13USf78ohyQ%3d From omeragacan at gmail.com Mon Feb 29 21:42:58 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Mon, 29 Feb 2016 16:42:58 -0500 Subject: CoreLint check for case with no alts In-Reply-To: <62193e132f15422c93d6154ed9a755da@DB4PR30MB030.064d.mgd.msft.net> References: <62193e132f15422c93d6154ed9a755da@DB4PR30MB030.064d.mgd.msft.net> Message-ID: > So feel free to make Lint cleverer; make sure you add a Note. But if it > /needs/ to be cleverer, that suggests that the simplifier should be cleverer > instead, and should simplify the code so that even a dumb Core Lint has no > trouble. Good point. The problem is linter is checking every intermediate Core, and apparently not all Core passes are that smart about simplifications. > In your example why didn't the simplifier do case-of-case? This code is generated by floatIn (FloatInwards). One more question. Do you think this is a safe change in coreToStgExpr that handles empty cases: coreToStgExpr (Case scrut bndr ty []) = coreToStgExpr (Case scrut bndr ty [(DEFAULT, [], mkImpossibleExpr ty)]) When I make this change some programs are failing with this: Oops! Entered absent arg w_sc1l FilePath But that may be because of some libraries I need to recompile, although I'm not sure why this would be the case. The problem I'm trying to solve is my lint-safe (after the smarter lint check about bottoming expressions) programs are failing with segfaults. Of course that may be because I'm doing something wrong in STG level, but I'm trying to make sure everything above STG is correct and bug-free. It'd be really great if I could somehow generate an erroring expression in some places that are supposed to be unreachable, just to make sure my segfaults are not related with those. 2016-02-29 6:32 GMT-05:00 Simon Peyton Jones : > | I wanted to ask: Is there a restriction on what kind empty case > | expressions are supported by the code generator or can I just improve > | the lint check and assume that the code will be handled by the code > | generator correctly? > > I believe the latter. See CoreToStg line 364. > > So feel free to make Lint cleverer; make sure you add a Note. But if it /needs/ to be cleverer, that suggests that the simplifier should be cleverer instead, and should simplify the code so that even a dumb Core Lint has no trouble. > > In your example why didn't the simplifier do case-of-case? > > I suppose that this might be after some pass and before a simplifier run. > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of ?mer > | Sinan Agacan > | Sent: 29 February 2016 03:16 > | To: ghc-devs > | Subject: CoreLint check for case with no alts > | > | Hi all, > | > | CoreLint has a check that, when seeing a case expression with empty > | list of alternatives, checks whether the scrutinee is bottom. This > | "bottom-ness" check is, however, very simple and returning many false > | negatives. For example, when it sees a case expression, all it does is: > | > | go _ (Case _ _ _ alts) = null alts > | > | Which is just too simple for some cases. (it could check if all the > | RHSs are bottom, or if the scrutinee is bottom etc.) > | > | I guess this makes sense, since it's OK to generate unreachable code, > | but it's not OK to not generate a code in a reachable path. > | > | But in my case this is becoming problem as it's rejecting my seemingly > | valid program. One of the relevant parts in my code is this: > | > | case ww_s4C3 of ww_X4Fb { > | (#_||#) ww_s4Ce -> > | case case ww_s4Ce of ww_s4F1 { (# ww_s4F2, ww_s4F3 #) -> > | lvl_s4F4 ww_s4F3 ww_s4F2 > | } > | of wild_00 { > | -- empty > | }; > | > | lvl_s4F4 :: Int# -> String -> Var > | [LclId, Arity=2, Str=DmdType (args: ) (res: x)] > | lvl_s4F4 = > | \ (ww_s4F3 :: Int#) (ww_s4F2 :: String) -> > | lvl_s3V4 (TyVar ww_s4F2 ww_s4F3) > | > | lvl_s3V4 :: Var -> Var > | [LclId, Arity=1, CallArity=1, Str=DmdType (args: ) (res: x)] > | lvl_s3V4 = \ (i_a1vO :: Var) -> lvl_s4EZ i_a1vO > | > | lvl_s4EZ :: Var -> Var > | [LclId, Arity=1, Str=DmdType (args: ) (res: x)] > | lvl_s4EZ = \ (i_a1vO :: Var) -> error ... > | > | The scrutinee part of the case expression in the alternative is clearly > | bottom, but this expression is rejected by the linter. > | > | One easy solution is to implement a more precise test and use it in > | linter. But I thought maybe the current implementation is deliberately > | so. Maybe the code generator doesn't support that type of code etc. so > | I wanted to ask: Is there a restriction on what kind empty case > | expressions are supported by the code generator or can I just improve > | the lint check and assume that the code will be handled by the code > | generator correctly? > | > | Thanks. > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha > | skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- > | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce621b9bcb2774ff8 > | 522208d340b6c5a7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=cIiMVTgiH > | ibh0SNksSZGLK75bZBgb3HA13USf78ohyQ%3d From simonpj at microsoft.com Mon Feb 29 22:03:26 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 29 Feb 2016 22:03:26 +0000 Subject: CoreLint check for case with no alts In-Reply-To: References: <62193e132f15422c93d6154ed9a755da@DB4PR30MB030.064d.mgd.msft.net> Message-ID: | coreToStgExpr (Case scrut bndr ty []) | = coreToStgExpr (Case scrut bndr ty [(DEFAULT, [], mkImpossibleExpr | ty)]) Yes that should be fine. I'm afraid I have no idea why you are getting | Oops! Entered absent arg w_sc1l FilePath or seg-faults. Simon | | But that may be because of some libraries I need to recompile, although I'm | not | sure why this would be the case. | | The problem I'm trying to solve is my lint-safe (after the smarter lint check | about bottoming expressions) programs are failing with segfaults. Of course | that may be because I'm doing something wrong in STG level, but I'm trying to | make sure everything above STG is correct and bug-free. It'd be really great | if | I could somehow generate an erroring expression in some places that are | supposed to be unreachable, just to make sure my segfaults are not related | with | those. | | 2016-02-29 6:32 GMT-05:00 Simon Peyton Jones : | > | I wanted to ask: Is there a restriction on what kind empty case | > | expressions are supported by the code generator or can I just improve | > | the lint check and assume that the code will be handled by the code | > | generator correctly? | > | > I believe the latter. See CoreToStg line 364. | > | > So feel free to make Lint cleverer; make sure you add a Note. But if it | /needs/ to be cleverer, that suggests that the simplifier should be cleverer | instead, and should simplify the code so that even a dumb Core Lint has no | trouble. | > | > In your example why didn't the simplifier do case-of-case? | > | > I suppose that this might be after some pass and before a simplifier run. | > | > Simon | > | > | -----Original Message----- | > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of ?mer | > | Sinan Agacan | > | Sent: 29 February 2016 03:16 | > | To: ghc-devs | > | Subject: CoreLint check for case with no alts | > | | > | Hi all, | > | | > | CoreLint has a check that, when seeing a case expression with empty | > | list of alternatives, checks whether the scrutinee is bottom. This | > | "bottom-ness" check is, however, very simple and returning many false | > | negatives. For example, when it sees a case expression, all it does is: | > | | > | go _ (Case _ _ _ alts) = null alts | > | | > | Which is just too simple for some cases. (it could check if all the | > | RHSs are bottom, or if the scrutinee is bottom etc.) | > | | > | I guess this makes sense, since it's OK to generate unreachable code, | > | but it's not OK to not generate a code in a reachable path. | > | | > | But in my case this is becoming problem as it's rejecting my seemingly | > | valid program. One of the relevant parts in my code is this: | > | | > | case ww_s4C3 of ww_X4Fb { | > | (#_||#) ww_s4Ce -> | > | case case ww_s4Ce of ww_s4F1 { (# ww_s4F2, ww_s4F3 #) -> | > | lvl_s4F4 ww_s4F3 ww_s4F2 | > | } | > | of wild_00 { | > | -- empty | > | }; | > | | > | lvl_s4F4 :: Int# -> String -> Var | > | [LclId, Arity=2, Str=DmdType (args: ) (res: x)] | > | lvl_s4F4 = | > | \ (ww_s4F3 :: Int#) (ww_s4F2 :: String) -> | > | lvl_s3V4 (TyVar ww_s4F2 ww_s4F3) | > | | > | lvl_s3V4 :: Var -> Var | > | [LclId, Arity=1, CallArity=1, Str=DmdType (args: ) (res: x)] | > | lvl_s3V4 = \ (i_a1vO :: Var) -> lvl_s4EZ i_a1vO | > | | > | lvl_s4EZ :: Var -> Var | > | [LclId, Arity=1, Str=DmdType (args: ) (res: x)] | > | lvl_s4EZ = \ (i_a1vO :: Var) -> error ... | > | | > | The scrutinee part of the case expression in the alternative is clearly | > | bottom, but this expression is rejected by the linter. | > | | > | One easy solution is to implement a more precise test and use it in | > | linter. But I thought maybe the current implementation is deliberately | > | so. Maybe the code generator doesn't support that type of code etc. so | > | I wanted to ask: Is there a restriction on what kind empty case | > | expressions are supported by the code generator or can I just improve | > | the lint check and assume that the code will be handled by the code | > | generator correctly? | > | | > | Thanks. | > | _______________________________________________ | > | ghc-devs mailing list | > | ghc-devs at haskell.org | > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha | > | skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | > | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce621b9bcb2774ff8 | > | 522208d340b6c5a7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=cIiMVTgiH | > | ibh0SNksSZGLK75bZBgb3HA13USf78ohyQ%3d From omeragacan at gmail.com Mon Feb 29 22:35:44 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Mon, 29 Feb 2016 17:35:44 -0500 Subject: Change in demand analysis results between 7.10.2 and RC1 (not fixed in RC2 and HEAD) In-Reply-To: References: Message-ID: > Why do you say > > | In our case, we prefer the result in 7.10.2 of course, because that's a > | more precise demand and it gives us more opportunities for > | optimizations. But I guess this could potentially reveal itself in some > > What optimisations do you have in mind? I just had worker/wrapper in mind. I just realized that is actually a very good demand for W/W, so this new demand is actually better. I was thinking naively that more strict is better, ignoring the cardinality analysis parts and redundant argument passing. 2016-02-29 5:10 GMT-05:00 Simon Peyton Jones : > See Note [Add demands for strict constructors] in DmdAnal, esp the bit that says > If the argument is not used at all in the alternative (i.e. it is > Absent), then *don't* add a 'seqDmd'. If we do, it makes it look used > and hence it'll be passed to the worker when it doesn't need to be. > Hence the isAbsDmd test in addDataConStrictness. > > Why do you say > > | In our case, we prefer the result in 7.10.2 of course, because that's a > | more precise demand and it gives us more opportunities for > | optimizations. But I guess this could potentially reveal itself in some > > What optimisations do you have in mind? > > Simon > > | -----Original Message----- > | From: ?mer Sinan A?acan [mailto:omeragacan at gmail.com] > | Sent: 27 February 2016 03:13 > | To: ghc-devs ; Simon Peyton Jones > | > | Cc: Jose Calderon > | Subject: Change in demand analysis results between 7.10.2 and RC1 (not > | fixed in RC2 and HEAD) > | > | Hi all, > | > | While working on demand analyzer today we realized that there has been > | some changes in demand analysis results between GHC 7.10.2 and 8.0-rc2. > | Here's a minimal example: > | > | {-# LANGUAGE BangPatterns #-} > | > | module Main where > | > | data Prod a = Prod !a !a > | > | addProd :: Prod Int -> Prod Int -> Prod Int > | addProd (Prod i1 i2) (Prod i3 i4) = Prod i1 (i2 + i4) > | > | main = return () > | > | Compiled with 7.10.2: > | > | addProd :: Prod Int -> Prod Int -> Prod Int > | [GblId, > | Arity=2, > | Caf=NoCafRefs, > | Str=DmdType m, > | ...}}}}] > | addProd = > | \ (ds_dzH :: Prod Int) (ds1_dzI :: Prod Int) -> > | case ds_dzH of _ [Occ=Dead] { Prod i1_an2 i2_an3 -> > | case i2_an3 of _ [Occ=Dead] { GHC.Types.I# x_s2B4 -> > | case ds1_dzI of _ [Occ=Dead] { Prod i3_an4 i4_an5 -> > | case i4_an5 of _ [Occ=Dead] { GHC.Types.I# y_s2B7 -> > | > | https://na01.safelinks.protection.outlook.com/?url=Main.Prod&data=01%7c > | 01%7csimonpj%40064d.mgd.microsoft.com%7c7b5d6e60d31348506eb108d33f23f6b > | f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=NfCiyeSjPwsWage0KlgkMkQR > | jWVexsdlCq0Dla%2f1I10%3d @ Int i1_an2 (GHC.Types.I# (GHC.Prim.+# x_s2B4 > | y_s2B7)) > | } > | } > | } > | } > | > | Compiled with 8.0-rc2: > | > | -- RHS size: {terms: 20, types: 17, coercions: 0} > | addProd :: Prod Int -> Prod Int -> Prod Int > | [GblId, > | Arity=2, > | Caf=NoCafRefs, > | Str=DmdType m, > | ...}}}}] > | addProd = > | \ (ds_dQL :: Prod Int) (ds1_dQM :: Prod Int) -> > | case ds_dQL of _ [Occ=Dead] { Prod i1_avS i2_avT -> > | case i2_avT of _ [Occ=Dead] { GHC.Types.I# x_s1vO -> > | case ds1_dQM of _ [Occ=Dead] { Prod i3_avU i4_avV -> > | case i4_avV of _ [Occ=Dead] { GHC.Types.I# y_s1vR -> > | > | https://na01.safelinks.protection.outlook.com/?url=Main.Prod&data=01%7c > | 01%7csimonpj%40064d.mgd.microsoft.com%7c7b5d6e60d31348506eb108d33f23f6b > | f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=NfCiyeSjPwsWage0KlgkMkQR > | jWVexsdlCq0Dla%2f1I10%3d @ Int i1_avS (GHC.Types.I# (GHC.Prim.+# x_s1vO > | y_s1vR)) > | } > | } > | } > | } > | > | To highlight the difference, > | > | GHC 7.10.2: > | GHC 8.0-rc2: > | > | (NOTE: Also tried with HEAD and rc1 just now, the results are the same > | as rc2) > | > | The demand put on the second argument is more strict in GHC 7.10. Was > | that an intentional change? Any ideas on why this might be happening? > | > | In our case, we prefer the result in 7.10.2 of course, because that's a > | more precise demand and it gives us more opportunities for > | optimizations. But I guess this could potentially reveal itself in some > | other situations and make some programs slower? Any ideas? > | > | Thanks..