From austin at well-typed.com Mon Nov 4 00:37:27 2013 From: austin at well-typed.com (Austin Seipp) Date: Sun, 3 Nov 2013 18:37:27 -0600 Subject: 7.8.1 RC Message-ID: Hello all, First and foremost, I realize that I said an RC was coming on Friday along with a branch, but I've unfortunately been a bit behind the gun this week, and several things more things have come to my attention recently. For the delay, I am very sorry. Here's an update on the most pertinent tickets and what needs to happen. One thing is that Herbert and I would like to upload many of the bootstrap libraries to hackage to coincide with the release, but this requires a server upgrade that should happen quite soon (thanks to Duncan/Herbert.) Herber and I also went over #8305, which should (in our opinion) certainly be part of the RC so issues can be filed, and clearly documented. Herbert has a patch for this, and I'll review it today. Second, the new OS X release, Mavericks (and, by association, XCode 5) seem to be a little confusing at the moment, and I don't have access to these machines quite yet. Only a Lion machine. One reason this is a delay is because I don't quite understand e.g. #8497 and #8493 in particular. There has also historically been some issues with different OS X builds not working on different platforms due to XCode and/or strange ABI issues, so I need to make my own to double check. Preprocessing seems to becoming a hot issue* on the note of #8493, and this also certainly needs attention once I get my hands on a machine. There's been a lot of pain around making all this 'work correctly', and working by proxy is simply becoming difficult I think, so I just need to dig into it a bit once I have my hands on something. Also relevant to this is that I'll be signing the announcement, and giving out tarballs with checksums(!), so some of these issues must be fixed for distribution (like #5987, which I am still investigating.) Finally, I have some incoming patches to fix a few of the critical priority bugs (related to Windows, mostly,) but they need to be polished and I need to investigate some other things related to them (e.g. due to lack of time, I only have a 'very slow path' fix for #8228, which is a bit annoying. And also this new msys2 thing.) * Richard Smith, if you're out there, I should have listened to you on the LLVM list. I'll learn from this one. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From simonpj at microsoft.com Wed Nov 6 10:55:09 2013 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed, 6 Nov 2013 10:55:09 +0000 Subject: Annotations Message-ID: <59543203684B2244980D7E4057D5FBC14866C163@DB3EX14MBXC308.europe.corp.microsoft.com> I've just noticed that there is no GHC language extension for annotations http://www.haskell.org/ghc/docs/latest/html/users_guide/extending-ghc.html#annotation-pragmas That feels like an oversight. Yes, they are in a pragma, but you may get an error message if you compile with a stage-1 compiler, for example. Plus, the language extensions should truthfully report what extra stuff you are using. I'm inclined to add a language extension "Annotations". * Without it {-# ANN ... #-} pragmas are ignored as comments * With it, they are treated as annotations Do you agree? I don't know whether this can (or even should) land in 7.8.1. Do you care either way? Guidance welcome Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Wed Nov 6 11:01:07 2013 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed, 6 Nov 2013 12:01:07 +0100 Subject: Annotations In-Reply-To: <59543203684B2244980D7E4057D5FBC14866C163@DB3EX14MBXC308.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC14866C163@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: I agree. I would like a warning if I use {-# ANN ... #-} without the language pragma. I clearly meant to write an annotation! On Wed, Nov 6, 2013 at 11:55 AM, Simon Peyton-Jones wrote: > I?ve just noticed that there is no GHC language extension for annotations > > > http://www.haskell.org/ghc/docs/latest/html/users_guide/extending-ghc.html#annotation-pragmas > > That feels like an oversight. Yes, they are in a pragma, but you may get > an error message if you compile with a stage-1 compiler, for example. > Plus, the language extensions should truthfully report what extra stuff you > are using. > > > > I?m inclined to add a language extension ?Annotations?. > > ? Without it {-# ANN ? #-} pragmas are ignored as comments > > ? With it, they are treated as annotations > > Do you agree? > > I don?t know whether this can (or even should) land in 7.8.1. Do you care > either way? > > Guidance welcome > > Simon > > > > *Microsoft Research Limited (company number 03369488) is registered in > England and Wales * > > *Registered office is at 21 Station Road, Cambridge, CB1 2FB* > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gergely at risko.hu Wed Nov 6 11:57:14 2013 From: gergely at risko.hu (Gergely Risko) Date: Wed, 06 Nov 2013 12:57:14 +0100 Subject: Annotations References: <59543203684B2244980D7E4057D5FBC14866C163@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: <87vc05hhet.fsf@gergely.risko.hu> On Wed, 6 Nov 2013 10:55:09 +0000, Simon Peyton-Jones writes: > I?m inclined to add a language extension ?Annotations?. > > ? Without it {-# ANN ? #-} pragmas are ignored as comments > > ? With it, they are treated as annotations > > Do you agree? I generally agree that this should be a language extension. My only worry is around the just implemented TH additions regarding annotations. I don't clearly see what would happen if: - a TH library exports a function that generates annotations when spliced. - and the user uses this function in a .hs file, - without specifying the language extension. I'd it to work even in that case. I guess the behavior in this corner case depends heavily on how this is actually implemented. If e.g. the reader is the only component that checks if the language extension is turned on, then I imagine that the TH way of putting in the annotation into the AST would just work. On the other hand if the reader recognizes the annotations either way and some component after TH splicing is checking for the language extension, then my use-case would blow up. TH currently is lenient in cases like this. E.g. if you know that a Name is exported from a module and you reference it directly, without importing it everything will just work. I'd like to have the same behavior for annotations. Thanks, Gergely From simonpj at microsoft.com Wed Nov 6 12:06:04 2013 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed, 6 Nov 2013 12:06:04 +0000 Subject: Annotations In-Reply-To: <87vc05hhet.fsf@gergely.risko.hu> References: <59543203684B2244980D7E4057D5FBC14866C163@DB3EX14MBXC308.europe.corp.microsoft.com> <87vc05hhet.fsf@gergely.risko.hu> Message-ID: <59543203684B2244980D7E4057D5FBC14866C32F@DB3EX14MBXC308.europe.corp.microsoft.com> | My only worry is around the just implemented TH additions regarding | annotations. I don't clearly see what would happen if: | - a TH library exports a function that generates annotations when | spliced. | - and the user uses this function in a .hs file, | - without specifying the language extension. But this is true for ANY language extension. If a TH library exports a function that generates (say) a type family declaration, and you splice that into a file, do you need -XTypeFamilies in the client file? I think currently you do. So your point is a good one but it's orthogonal. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Gergely Risko | Sent: 06 November 2013 11:57 | To: ghc-devs at haskell.org | Cc: glasgow-haskell-users at haskell.org | Subject: Re: Annotations | | On Wed, 6 Nov 2013 10:55:09 +0000, Simon Peyton-Jones | writes: | | > I?m inclined to add a language extension ?Annotations?. | > | > ? Without it {-# ANN ? #-} pragmas are ignored as comments | > | > ? With it, they are treated as annotations | > | > Do you agree? | | I generally agree that this should be a language extension. | | My only worry is around the just implemented TH additions regarding | annotations. I don't clearly see what would happen if: | - a TH library exports a function that generates annotations when | spliced. | - and the user uses this function in a .hs file, | - without specifying the language extension. | | I'd it to work even in that case. | | I guess the behavior in this corner case depends heavily on how this is | actually implemented. If e.g. the reader is the only component that | checks if the language extension is turned on, then I imagine that the | TH way of putting in the annotation into the AST would just work. | | On the other hand if the reader recognizes the annotations either way | and some component after TH splicing is checking for the language | extension, then my use-case would blow up. | | TH currently is lenient in cases like this. E.g. if you know that a | Name is exported from a module and you reference it directly, without | importing it everything will just work. I'd like to have the same | behavior for annotations. | | Thanks, | Gergely | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From ekmett at gmail.com Wed Nov 6 12:48:01 2013 From: ekmett at gmail.com (Edward A Kmett) Date: Wed, 6 Nov 2013 07:48:01 -0500 Subject: Annotations In-Reply-To: <87vc05hhet.fsf@gergely.risko.hu> References: <59543203684B2244980D7E4057D5FBC14866C163@DB3EX14MBXC308.europe.corp.microsoft.com> <87vc05hhet.fsf@gergely.risko.hu> Message-ID: <32CC779B-7964-4F26-BA81-EB40CD28FCDB@gmail.com> Currently, in all the cases I can think of if the splice generates something that uses an extension then the module must have that flag turned on. Sent from my iPhone > On Nov 6, 2013, at 6:57 AM, Gergely Risko wrote: > > On Wed, 6 Nov 2013 10:55:09 +0000, Simon Peyton-Jones writes: > >> I?m inclined to add a language extension ?Annotations?. >> >> ? Without it {-# ANN ? #-} pragmas are ignored as comments >> >> ? With it, they are treated as annotations >> >> Do you agree? > > I generally agree that this should be a language extension. > > My only worry is around the just implemented TH additions regarding > annotations. I don't clearly see what would happen if: > - a TH library exports a function that generates annotations when spliced. > - and the user uses this function in a .hs file, > - without specifying the language extension. > > I'd it to work even in that case. > > I guess the behavior in this corner case depends heavily on how this is > actually implemented. If e.g. the reader is the only component that > checks if the language extension is turned on, then I imagine that the > TH way of putting in the annotation into the AST would just work. > > On the other hand if the reader recognizes the annotations either way > and some component after TH splicing is checking for the language > extension, then my use-case would blow up. > > TH currently is lenient in cases like this. E.g. if you know that a > Name is exported from a module and you reference it directly, without > importing it everything will just work. I'd like to have the same > behavior for annotations. > > Thanks, > Gergely > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From gergely at risko.hu Wed Nov 6 15:00:09 2013 From: gergely at risko.hu (Gergely Risko) Date: Wed, 06 Nov 2013 16:00:09 +0100 Subject: Annotations References: <59543203684B2244980D7E4057D5FBC14866C163@DB3EX14MBXC308.europe.corp.microsoft.com> <87vc05hhet.fsf@gergely.risko.hu> <59543203684B2244980D7E4057D5FBC14866C32F@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: <8761s5h8xy.fsf@gergely.risko.hu> [this is also my reply to Ekmett's comment] On Wed, 6 Nov 2013 12:06:04 +0000, Simon Peyton-Jones writes: > But this is true for ANY language extension. If a TH library exports a > function that generates (say) a type family declaration, and you > splice that into a file, do you need -XTypeFamilies in the client > file? I think currently you do. So, we've made a little bit of testing on this. There are a lot of extensions that simply can't be used with TH: - n+k, - RecursiveDo, - TransformListComp, - Arrows, - ImplicitParams, - TupleSections, - Monadcomprehensions. The rest can be grouped into two parts. The following extensions still work when spliced in without the corresponding language pragma: - UnicodeSyntax, - LambdaCase, - NamedFieldPuns, - RecordWildCards, - DataTypeContexts (and you get rid of the deprecation warning generation this way :)), - ConstraintKind, - MagicHash (note that UnboxedTuples is in the other part), - TraditionalRecordSyntax, - MultiWayIf, - GADTs (extra nice example at the end of this message). The following needs the pragma at the place of splicing: - PostfixOperators, - ScopedTypeVariables, - Rank2, RankN, - deriving typeable and data, - UnboxedTuples, - ViewPatterns, - ParallelListComp, - ExistentialQuantification, - EmptyDataDecls, - TypeFamilies, - MultiParamTypeClasses, - FunctionalDependencies. I don't see any trivial distinction, like based on Reader vs Typechecker or anything like that. Note ViewPatterns vs LambdaCase. Note GADTs vs Rank2. A very interesting example is ExplicitForAll. The AST for polymorphic functions always have explicit foralls in TH.Syntax; so there is no way to require the user at the point of splicing to enable the language extension. GADTs are cool to: ------------------------------ {-# LANGUAGE TemplateHaskell #-} -- No need for GADTs at all! -- {-# LANGUAGE GADTs #-} $([d| data Foo where Foo1 :: Int -> Foo Foo2 :: String -> Foo f1 :: Foo f1 = Foo1 5 f :: Foo -> Either Int String f (Foo1 n) = Left n f (Foo2 s) = Right s |]) main = print (f f1) ------------------------------ So all I'm asking for is that if it's not very inconvenient for the implementor, please put the Annotations language pragma into the first group. :) Thanks, Gergely From qdunkan at gmail.com Thu Nov 7 05:03:48 2013 From: qdunkan at gmail.com (Evan Laforge) Date: Wed, 6 Nov 2013 21:03:48 -0800 Subject: love for hpc? Message-ID: Is anyone out there using HPC? It seems like it was gotten into a more or less working if not ideal state, and then abandoned. Things I've noticed lately: The GHC runtime just quits on the spot if there's already a tix file. This bit me when I was parallelizing tests. It's also completely unsafe when run concurrently, mostly it just overwrites the file, sometimes it quits. Sure to cause headaches for someone trying to parallelize tests. You can't change the name of the output tix file, so I worked around by hardlinking the binary to a bunch of new ones, and then doing 'hpc sum' on the results. The hpc command is super slow. It might have to do with it doing its parsing with Prelude's 'read', and it certainly doesn't help the error msgs. And the whole thing is generally minimally documented. I can already predict the answer will be "yes, HPC could use some love, roll up your sleeves and welcome!" It does look like it could be improved a lot with just a bit of effort, but that would be a yak too far for me, at the moment. I'm presently just curious if anyone else out there is using it, and if they feel like it could do with a bit of polishing. From carter.schonwald at gmail.com Thu Nov 7 05:29:24 2013 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 7 Nov 2013 00:29:24 -0500 Subject: love for hpc? In-Reply-To: References: Message-ID: Evan, if you want to get involved in working on HPC, go for it! theres many many pieces of ghc that need more proactive ownership. i should probably use HPC a bit as i start getting my numerical libs out, and i'm sure future me will appreciate current you working on making it better -Carter On Thu, Nov 7, 2013 at 12:03 AM, Evan Laforge wrote: > Is anyone out there using HPC? It seems like it was gotten into a > more or less working if not ideal state, and then abandoned. > > Things I've noticed lately: > > The GHC runtime just quits on the spot if there's already a tix file. > This bit me when I was parallelizing tests. It's also completely > unsafe when run concurrently, mostly it just overwrites the file, > sometimes it quits. Sure to cause headaches for someone trying to > parallelize tests. > > You can't change the name of the output tix file, so I worked around > by hardlinking the binary to a bunch of new ones, and then doing 'hpc > sum' on the results. > > The hpc command is super slow. It might have to do with it doing its > parsing with Prelude's 'read', and it certainly doesn't help the error > msgs. > > And the whole thing is generally minimally documented. > > I can already predict the answer will be "yes, HPC could use some > love, roll up your sleeves and welcome!" It does look like it could > be improved a lot with just a bit of effort, but that would be a yak > too far for me, at the moment. I'm presently just curious if anyone > else out there is using it, and if they feel like it could do with a > bit of polishing. > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Thu Nov 7 07:55:45 2013 From: roma at ro-che.info (Roman Cheplyaka) Date: Thu, 7 Nov 2013 09:55:45 +0200 Subject: love for hpc? In-Reply-To: References: Message-ID: <20131107075545.GA23540@sniper> So Evan's prediction was accurate ;-) * Carter Schonwald [2013-11-07 00:29:24-0500] > Evan, > > if you want to get involved in working on HPC, go for it! theres many many > pieces of ghc that need more proactive ownership. > > i should probably use HPC a bit as i start getting my numerical libs out, > and i'm sure future me will appreciate current you working on making it > better > > -Carter > > > On Thu, Nov 7, 2013 at 12:03 AM, Evan Laforge wrote: > > > Is anyone out there using HPC? It seems like it was gotten into a > > more or less working if not ideal state, and then abandoned. > > > > Things I've noticed lately: > > > > The GHC runtime just quits on the spot if there's already a tix file. > > This bit me when I was parallelizing tests. It's also completely > > unsafe when run concurrently, mostly it just overwrites the file, > > sometimes it quits. Sure to cause headaches for someone trying to > > parallelize tests. > > > > You can't change the name of the output tix file, so I worked around > > by hardlinking the binary to a bunch of new ones, and then doing 'hpc > > sum' on the results. > > > > The hpc command is super slow. It might have to do with it doing its > > parsing with Prelude's 'read', and it certainly doesn't help the error > > msgs. > > > > And the whole thing is generally minimally documented. > > > > I can already predict the answer will be "yes, HPC could use some > > love, roll up your sleeves and welcome!" It does look like it could > > be improved a lot with just a bit of effort, but that would be a yak > > too far for me, at the moment. I'm presently just curious if anyone > > else out there is using it, and if they feel like it could do with a > > bit of polishing. > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users at haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From johan.tibell at gmail.com Thu Nov 7 08:45:07 2013 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 7 Nov 2013 09:45:07 +0100 Subject: love for hpc? In-Reply-To: <20131107075545.GA23540@sniper> References: <20131107075545.GA23540@sniper> Message-ID: Aside: cabal supports hpc and puts the various files (e.g. .tix) in separate directories to avoid problems like these. On Thu, Nov 7, 2013 at 8:55 AM, Roman Cheplyaka wrote: > So Evan's prediction was accurate ;-) > > * Carter Schonwald [2013-11-07 00:29:24-0500] > > Evan, > > > > if you want to get involved in working on HPC, go for it! theres many > many > > pieces of ghc that need more proactive ownership. > > > > i should probably use HPC a bit as i start getting my numerical libs out, > > and i'm sure future me will appreciate current you working on making it > > better > > > > -Carter > > > > > > On Thu, Nov 7, 2013 at 12:03 AM, Evan Laforge wrote: > > > > > Is anyone out there using HPC? It seems like it was gotten into a > > > more or less working if not ideal state, and then abandoned. > > > > > > Things I've noticed lately: > > > > > > The GHC runtime just quits on the spot if there's already a tix file. > > > This bit me when I was parallelizing tests. It's also completely > > > unsafe when run concurrently, mostly it just overwrites the file, > > > sometimes it quits. Sure to cause headaches for someone trying to > > > parallelize tests. > > > > > > You can't change the name of the output tix file, so I worked around > > > by hardlinking the binary to a bunch of new ones, and then doing 'hpc > > > sum' on the results. > > > > > > The hpc command is super slow. It might have to do with it doing its > > > parsing with Prelude's 'read', and it certainly doesn't help the error > > > msgs. > > > > > > And the whole thing is generally minimally documented. > > > > > > I can already predict the answer will be "yes, HPC could use some > > > love, roll up your sleeves and welcome!" It does look like it could > > > be improved a lot with just a bit of effort, but that would be a yak > > > too far for me, at the moment. I'm presently just curious if anyone > > > else out there is using it, and if they feel like it could do with a > > > bit of polishing. > > > _______________________________________________ > > > Glasgow-haskell-users mailing list > > > Glasgow-haskell-users at haskell.org > > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > > > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users at haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hesselink at gmail.com Thu Nov 7 09:21:00 2013 From: hesselink at gmail.com (Erik Hesselink) Date: Thu, 7 Nov 2013 10:21:00 +0100 Subject: love for hpc? In-Reply-To: References: Message-ID: I use HPC. It's really powerful in combination with tests, to see how much of your code is covered. But I have also run into some of the problems you mention, mostly to do with tix files. Erik On Thu, Nov 7, 2013 at 6:03 AM, Evan Laforge wrote: > Is anyone out there using HPC? It seems like it was gotten into a > more or less working if not ideal state, and then abandoned. > > Things I've noticed lately: > > The GHC runtime just quits on the spot if there's already a tix file. > This bit me when I was parallelizing tests. It's also completely > unsafe when run concurrently, mostly it just overwrites the file, > sometimes it quits. Sure to cause headaches for someone trying to > parallelize tests. > > You can't change the name of the output tix file, so I worked around > by hardlinking the binary to a bunch of new ones, and then doing 'hpc > sum' on the results. > > The hpc command is super slow. It might have to do with it doing its > parsing with Prelude's 'read', and it certainly doesn't help the error > msgs. > > And the whole thing is generally minimally documented. > > I can already predict the answer will be "yes, HPC could use some > love, roll up your sleeves and welcome!" It does look like it could > be improved a lot with just a bit of effort, but that would be a yak > too far for me, at the moment. I'm presently just curious if anyone > else out there is using it, and if they feel like it could do with a > bit of polishing. > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From daniel.trstenjak at gmail.com Thu Nov 7 11:52:34 2013 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Thu, 7 Nov 2013 12:52:34 +0100 Subject: GHC error message on type mismatch Message-ID: <20131107115234.GA815@machine> Hello, I don't know if I'm the only one struggeling with this GHC error message on type mismatches or it's because I'm not a full time Haskeller, or because I'm not a native english speaker. Couldn't match type `A' with `B? Expected type: B Actual type: A My problem is with 'Expected' and 'Actual', that I'm often unsure if the compiler is "expecting" something or if I'm the expecting one and the same goes for "actual". I know that the compiler is the expecting one and that I'm given the actual thing, but it's quite often that I'm looking at this error and have to repeat this reasoning. It's strange, because normaly I can memorize such things quite good, but this one bothers me. Perhaps it would be easier for myself if 'Actual type' would be called e.g. 'Given type', I don't know, that just one of the two has a less generic meaning. Greetings, Daniel From dluposchainsky at googlemail.com Thu Nov 7 12:22:51 2013 From: dluposchainsky at googlemail.com (David Luposchainsky) Date: Thu, 07 Nov 2013 13:22:51 +0100 Subject: GHC error message on type mismatch In-Reply-To: <20131107115234.GA815@machine> References: <20131107115234.GA815@machine> Message-ID: <527B861B.6070702@gmail.com> On 2013-11-07 12:52, Daniel Trstenjak wrote: > My problem is with 'Expected' and 'Actual', that I'm often unsure if > the compiler is "expecting" something or if I'm the expecting one > and the same goes for "actual". Funny you mention it; I think I just got too used to the fact that every time I see this error I have to take a step back to remember what it means exactly. Renaming it to "given" or "provided" would really help. +1 David From simonpj at microsoft.com Thu Nov 7 14:02:06 2013 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu, 7 Nov 2013 14:02:06 +0000 Subject: GHC error message on type mismatch In-Reply-To: <527B861B.6070702@gmail.com> References: <20131107115234.GA815@machine> <527B861B.6070702@gmail.com> Message-ID: <59543203684B2244980D7E4057D5FBC14866DA5D@DB3EX14MBXC308.europe.corp.microsoft.com> The motivation is this. Consider f True where f :: Int -> Char Then f *expects* an argument of type Int but the *actual* argument has type Bool Does that help? Simon | -----Original Message----- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | bounces at haskell.org] On Behalf Of David Luposchainsky | Sent: 07 November 2013 12:23 | To: Daniel Trstenjak; glasgow-haskell-users at haskell.org | Subject: Re: GHC error message on type mismatch | | On 2013-11-07 12:52, Daniel Trstenjak wrote: | > My problem is with 'Expected' and 'Actual', that I'm often unsure if | > the compiler is "expecting" something or if I'm the expecting one | > and the same goes for "actual". | | Funny you mention it; I think I just got too used to the fact that every | time I see this error I have to take a step back to remember what it | means exactly. Renaming it to "given" or "provided" would really help. | | +1 | | David | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users at haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From dsf at seereason.com Thu Nov 7 14:21:03 2013 From: dsf at seereason.com (David Fox) Date: Thu, 7 Nov 2013 06:21:03 -0800 Subject: GHC error message on type mismatch In-Reply-To: <59543203684B2244980D7E4057D5FBC14866DA5D@DB3EX14MBXC308.europe.corp.microsoft.com> References: <20131107115234.GA815@machine> <527B861B.6070702@gmail.com> <59543203684B2244980D7E4057D5FBC14866DA5D@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: It *is* sometimes difficult to remember that my expectations and I are not part of this equation - it might be a better prompt to say something like type mismatch between function parameter and supplied value: function parameter type: A supplied value type: B On Thu, Nov 7, 2013 at 6:02 AM, Simon Peyton-Jones wrote: > The motivation is this. Consider > > f True > > where f :: Int -> Char > > Then > f *expects* an argument of type Int > but the *actual* argument has type Bool > > Does that help? > > Simon > > | -----Original Message----- > | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- > | bounces at haskell.org] On Behalf Of David Luposchainsky > | Sent: 07 November 2013 12:23 > | To: Daniel Trstenjak; glasgow-haskell-users at haskell.org > | Subject: Re: GHC error message on type mismatch > | > | On 2013-11-07 12:52, Daniel Trstenjak wrote: > | > My problem is with 'Expected' and 'Actual', that I'm often unsure if > | > the compiler is "expecting" something or if I'm the expecting one > | > and the same goes for "actual". > | > | Funny you mention it; I think I just got too used to the fact that every > | time I see this error I have to take a step back to remember what it > | means exactly. Renaming it to "given" or "provided" would really help. > | > | +1 > | > | David > | > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users at haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecrockett0 at gmail.com Thu Nov 7 19:11:36 2013 From: ecrockett0 at gmail.com (crockeea) Date: Thu, 7 Nov 2013 11:11:36 -0800 (PST) Subject: match_co: needs more cases In-Reply-To: <59543203684B2244980D7E4057D5FBC1481CEAE6@DB3EX14MBXC310.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC1481CEAE6@DB3EX14MBXC310.europe.corp.microsoft.com> Message-ID: <1383851496549-5739541.post@n5.nabble.com> I got this error with a small example, so I thought I'd post it for you. I could only get it to work when split over two files. Main.hs: import qualified Data.Vector.Unboxed as U import Helper main = do let iters = 100 dim = 221184 y = U.replicate dim 0 :: U.Vector (ZqW M) let ans = iterate (f y) y !! iters putStr $ (show $ U.foldl1' (+) ans) Helper.hs {-# LANGUAGE FlexibleContexts, StandaloneDeriving, GeneralizedNewtypeDeriving, MultiParamTypeClasses #-} module VectorTestHelper (ZqW,f,M) where import qualified Data.Vector.Unboxed as U import qualified Data.Vector.Generic as V import Data.Vector.Generic.Mutable as M f :: (Num r, V.Vector v r) => v r -> v r -> v r {-# SPECIALIZE f :: (Num (ZqW m Int)) => U.Vector (ZqW m Int) -> U.Vector (ZqW m Int) -> U.Vector (ZqW m Int) #-} f x y = V.zipWith (+) x y newtype ZqW p i = T i deriving (U.Unbox, Show) deriving instance (U.Unbox i) => V.Vector U.Vector (ZqW p i) deriving instance (U.Unbox i) => MVector U.MVector (ZqW p i) class Foo a b data M instance Foo M Int instance (Foo p i, Integral i) => Num (ZqW p i) where (T a) + (T b) = T $ (a+b) fromInteger x = T $ fromInteger x It's possible I'm abusing SPECIALIZE here, but I'm trying to get Unboxed vector specialization, even though I have a phantom type. (In practice, the phantom will represent a modulus and will be used in the Num instance). When compiling with GHC 7.6.2 and -O2, I get a dozen or so "match_co: needs more cases" warnings. Indeed, based on the runtime, it appears that specialization is not happening. How to actually make this work is a whole different question... -- View this message in context: http://haskell.1045720.n5.nabble.com/match-co-needs-more-cases-tp5730855p5739541.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From qdunkan at gmail.com Fri Nov 8 00:17:03 2013 From: qdunkan at gmail.com (Evan Laforge) Date: Thu, 7 Nov 2013 16:17:03 -0800 Subject: match_co: needs more cases In-Reply-To: <1383851496549-5739541.post@n5.nabble.com> References: <59543203684B2244980D7E4057D5FBC1481CEAE6@DB3EX14MBXC310.europe.corp.microsoft.com> <1383851496549-5739541.post@n5.nabble.com> Message-ID: On Thu, Nov 7, 2013 at 11:11 AM, crockeea wrote: > I got this error with a small example, so I thought I'd post it for you. I > could only get it to work when split over two files. Mine is similar, sorry I've been lazy about getting a small reproduction, I assumed it wasn't too important. I have a generic library that uses Data.Vector.Generic, along with a bunch of SPECIALIZE and INLINEABLE for a particular monomorphic Unboxed use. I don't know about the INLINEABLE, but the SPECIALIZE does wonders for performance, otherwise it doesn't notice that the operation can be unboxed. So it's a bit worrisome to me if the SPECIALIZEs aren't firing. I did profiling before and they made my vector operations fall off of the expensive list, but that was before upgrading ghc and getting the new error msgs. Would it be useful for me to boil down my example too, or is this one enough to work on? Mine is simpler in that it specializes to a monomorphic Storable.Vector Double. From carter.schonwald at gmail.com Fri Nov 8 00:20:26 2013 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 7 Nov 2013 19:20:26 -0500 Subject: match_co: needs more cases In-Reply-To: References: <59543203684B2244980D7E4057D5FBC1481CEAE6@DB3EX14MBXC310.europe.corp.microsoft.com> <1383851496549-5739541.post@n5.nabble.com> Message-ID: specialize only fires on functions that have type class constraints / are part of a type class. Furthermore, the function needs to be marked INLINEABLE or INLINE for specialization to work (unless the specialize pragma was written in the defining module) not sure if that helps, cheers -Carter On Thu, Nov 7, 2013 at 7:17 PM, Evan Laforge wrote: > On Thu, Nov 7, 2013 at 11:11 AM, crockeea wrote: > > I got this error with a small example, so I thought I'd post it for you. > I > > could only get it to work when split over two files. > > Mine is similar, sorry I've been lazy about getting a small > reproduction, I assumed it wasn't too important. > > I have a generic library that uses Data.Vector.Generic, along with a > bunch of SPECIALIZE and INLINEABLE for a particular monomorphic > Unboxed use. I don't know about the INLINEABLE, but the SPECIALIZE > does wonders for performance, otherwise it doesn't notice that the > operation can be unboxed. > > So it's a bit worrisome to me if the SPECIALIZEs aren't firing. I did > profiling before and they made my vector operations fall off of the > expensive list, but that was before upgrading ghc and getting the new > error msgs. > > Would it be useful for me to boil down my example too, or is this one > enough to work on? Mine is simpler in that it specializes to a > monomorphic Storable.Vector Double. > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From qdunkan at gmail.com Fri Nov 8 00:45:37 2013 From: qdunkan at gmail.com (Evan Laforge) Date: Thu, 7 Nov 2013 16:45:37 -0800 Subject: match_co: needs more cases In-Reply-To: References: <59543203684B2244980D7E4057D5FBC1481CEAE6@DB3EX14MBXC310.europe.corp.microsoft.com> <1383851496549-5739541.post@n5.nabble.com> Message-ID: On Thu, Nov 7, 2013 at 4:20 PM, Carter Schonwald wrote: > specialize only fires on functions that have type class constraints / are > part of a type class. Furthermore, the function needs to be marked > INLINEABLE or INLINE for specialization to work (unless the specialize > pragma was written in the defining module) Right, and I added it because I wanted to get rid of both the Vector.Generic typeclass, and the Unboxed typeclass, and it worked. I guess that's why I added INLINEABLEs too, I probably read about it in the documentation and then forgot. But if crockeea is right and it's no longer happening, that would be unfortunate. I wonder if you could write a kind of query language for core, to ask things like "are the arguments to this function unboxed?" or "how many list constructors are called here" (e.g. to check for fusion). > not sure if that helps, It does, thanks! From daniel.trstenjak at gmail.com Fri Nov 8 04:54:49 2013 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Fri, 8 Nov 2013 05:54:49 +0100 Subject: GHC error message on type mismatch In-Reply-To: <59543203684B2244980D7E4057D5FBC14866DA5D@DB3EX14MBXC308.europe.corp.microsoft.com> References: <20131107115234.GA815@machine> <527B861B.6070702@gmail.com> <59543203684B2244980D7E4057D5FBC14866DA5D@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: <20131108045449.GA2057@machine> Hi Simon, On Thu, Nov 07, 2013 at 02:02:06PM +0000, Simon Peyton-Jones wrote: > The motivation is this. Consider > > f True > > where f :: Int -> Char > > Then > f *expects* an argument of type Int > but the *actual* argument has type Bool > > Does that help? If you would switch the meaning of 'Expected' and 'Actual', than it still could make perfectly sense and my brain seems to tend to this switched meaning. I think my main issue is the word 'Actual'. I seem to associate something more authoritative with this word and not just a wrongly given type by the user, and on the other side 'Expected' doesn't feel authoritative enough. Yes, I think the combination of the words 'Expected' and 'Actual' is irritating me and that I'm perceiving 'Actual' as the more authoritative one. Perhaps: Couldn't match type `A' with `B? Real type: B Given type: A Or instead of 'Given', like others have suggested: 'Provided' or 'Supplied'. Greetings, Daniel From carter.schonwald at gmail.com Fri Nov 8 05:19:05 2013 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 8 Nov 2013 00:19:05 -0500 Subject: GHC error message on type mismatch In-Reply-To: <20131108045449.GA2057@machine> References: <20131107115234.GA815@machine> <527B861B.6070702@gmail.com> <59543203684B2244980D7E4057D5FBC14866DA5D@DB3EX14MBXC308.europe.corp.microsoft.com> <20131108045449.GA2057@machine> Message-ID: i'm not sure how change the words to synonyms helps communicate the exact same thing better, :) That said, once you start digging into really really fancy types, you'll certainly discover examples where the error messages are confusing and need some care to better communicate what is indeed the error. Point being: as you get into trying out really really fancy types, please feel welcome to share examples where the resulting error messages seem lacking / down right confusing. (though asking for help on the cafe list or #haskell on irc first is probably the first place to go, of course) On Thu, Nov 7, 2013 at 11:54 PM, Daniel Trstenjak < daniel.trstenjak at gmail.com> wrote: > > Hi Simon, > > On Thu, Nov 07, 2013 at 02:02:06PM +0000, Simon Peyton-Jones wrote: > > The motivation is this. Consider > > > > f True > > > > where f :: Int -> Char > > > > Then > > f *expects* an argument of type Int > > but the *actual* argument has type Bool > > > > Does that help? > > If you would switch the meaning of 'Expected' and 'Actual', than it > still could make perfectly sense and my brain seems to tend to this > switched meaning. > > I think my main issue is the word 'Actual'. I seem to associate > something more authoritative with this word and not just a wrongly given > type by the user, and on the other side 'Expected' doesn't feel > authoritative > enough. > > Yes, I think the combination of the words 'Expected' and 'Actual' is > irritating me and that I'm perceiving 'Actual' as the more authoritative > one. > > > Perhaps: > > Couldn't match type `A' with `B? > Real type: B > Given type: A > > > Or instead of 'Given', like others have suggested: 'Provided' or > 'Supplied'. > > > Greetings, > Daniel > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From difrumin at gmail.com Fri Nov 8 05:30:54 2013 From: difrumin at gmail.com (Dan Frumin) Date: Fri, 8 Nov 2013 00:30:54 -0500 Subject: GHC error message on type mismatch In-Reply-To: <20131108045449.GA2057@machine> References: <20131107115234.GA815@machine> <527B861B.6070702@gmail.com> <59543203684B2244980D7E4057D5FBC14866DA5D@DB3EX14MBXC308.europe.corp.microsoft.com> <20131108045449.GA2057@machine> Message-ID: Hi everyone > On 07 Nov 2013, at 23:54, Daniel Trstenjak wrote: > > > Hi Simon, > >> On Thu, Nov 07, 2013 at 02:02:06PM +0000, Simon Peyton-Jones wrote: >> The motivation is this. Consider >> >> f True >> >> where f :: Int -> Char >> >> Then >> f *expects* an argument of type Int >> but the *actual* argument has type Bool >> >> Does that help? > > If you would switch the meaning of 'Expected' and 'Actual', than it > still could make perfectly sense and my brain seems to tend to this > switched meaning. > Yeah I can see how that may happen. f's argument type is *actually* an Int, but it was used in a way that caller *expects* it to have a type Bool > I think my main issue is the word 'Actual'. I seem to associate > something more authoritative with this word and not just a wrongly given > type by the user, and on the other side 'Expected' doesn't feel authoritative > enough. > > Yes, I think the combination of the words 'Expected' and 'Actual' is > irritating me and that I'm perceiving 'Actual' as the more authoritative one. > > > Perhaps: > > Couldn't match type `A' with `B? > Real type: B > Given type: A > > > Or instead of 'Given', like others have suggested: 'Provided' or 'Supplied'. > > > Greetings, > Daniel > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From roma at ro-che.info Fri Nov 8 07:17:03 2013 From: roma at ro-che.info (Roman Cheplyaka) Date: Fri, 8 Nov 2013 09:17:03 +0200 Subject: GHC error message on type mismatch In-Reply-To: <20131108045449.GA2057@machine> References: <20131107115234.GA815@machine> <527B861B.6070702@gmail.com> <59543203684B2244980D7E4057D5FBC14866DA5D@DB3EX14MBXC308.europe.corp.microsoft.com> <20131108045449.GA2057@machine> Message-ID: <20131108071703.GA15186@sniper> * Daniel Trstenjak [2013-11-08 05:54:49+0100] > Perhaps: > > Couldn't match type `A' with `B? > Real type: B > Given type: A > > > Or instead of 'Given', like others have suggested: 'Provided' or 'Supplied'. So far in this thread I haven't seen any suggestions better than status quo. E.g.: Prelude> (undefined :: Int -> Bool) (undefined :: Bool) :2:29: Couldn't match expected type `Int' with actual type `Bool' In the first argument of `undefined :: Int -> Bool', namely `(undefined :: Bool)' In the expression: (undefined :: Int -> Bool) (undefined :: Bool) In an equation for `it': it = (undefined :: Int -> Bool) (undefined :: Bool) This one is quite clear ? the compiler expected an argument of type Int, but it was of type Bool. Now replace this with Real and Given. Well, Bool for the function argument is both Real and Given (I gave it this type, and it became its real type). And calling Int either Real or Given doesn't make any sense. Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From qdunkan at gmail.com Fri Nov 8 08:01:13 2013 From: qdunkan at gmail.com (Evan Laforge) Date: Fri, 8 Nov 2013 00:01:13 -0800 Subject: GHC error message on type mismatch In-Reply-To: <527B861B.6070702@gmail.com> References: <20131107115234.GA815@machine> <527B861B.6070702@gmail.com> Message-ID: On Thu, Nov 7, 2013 at 4:22 AM, David Luposchainsky wrote: > On 2013-11-07 12:52, Daniel Trstenjak wrote: >> My problem is with 'Expected' and 'Actual', that I'm often unsure if >> the compiler is "expecting" something or if I'm the expecting one >> and the same goes for "actual". > > Funny you mention it; I think I just got too used to the fact that every > time I see this error I have to take a step back to remember what it > means exactly. Renaming it to "given" or "provided" would really help. For what it's worth, I used to have the same confusion. But after a few years it went away. Now it seems obvious and I don't really understand how I was confused before, or how I got unconfused. That's the classic problem with trying to make anything intuitive. When I write my own typecheck msgs, I always write "Function expected X, but received Y." That's not too far off from expected / actual, though at least it has an explicit subject. From daniel.trstenjak at gmail.com Fri Nov 8 08:32:13 2013 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Fri, 8 Nov 2013 09:32:13 +0100 Subject: GHC error message on type mismatch In-Reply-To: References: <20131107115234.GA815@machine> <527B861B.6070702@gmail.com> Message-ID: <20131108083213.GA6459@machine> On Fri, Nov 08, 2013 at 12:01:13AM -0800, Evan Laforge wrote: > When I write my own typecheck msgs, I always write "Function expected > X, but received Y." That's not too far off from expected / actual, > though at least it has an explicit subject. That's perfectly fine, because 'Function + expected' is pointing to the compiler side and additionally 'received' is pointing to the user side. From marlowsd at gmail.com Fri Nov 8 09:27:44 2013 From: marlowsd at gmail.com (Simon Marlow) Date: Fri, 08 Nov 2013 09:27:44 +0000 Subject: Annotations In-Reply-To: <59543203684B2244980D7E4057D5FBC14866C163@DB3EX14MBXC308.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC14866C163@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: <527CAE90.8060003@gmail.com> Simon, Austin and I discussed this briefly yesterday. There's an existing ticket: http://ghc.haskell.org/trac/ghc/ticket/4268 I added a comment to the ticket to summarise our conclusion: we won't add a flag for the pragma, however we should add a warning when an ANN pragma is being ignored. On 06/11/2013 10:55, Simon Peyton-Jones wrote: > I?ve just noticed that there is no GHC language extension for annotations > > http://www.haskell.org/ghc/docs/latest/html/users_guide/extending-ghc.html#annotation-pragmas > > That feels like an oversight. Yes, they are in a pragma, but you may get > an error message if you compile with a stage-1 compiler, for example. > Plus, the language extensions should truthfully report what extra stuff > you are using. > > I?m inclined to add a language extension ?Annotations?. > > ?Without it {-# ANN ? #-} pragmas are ignored as comments > > ?With it, they are treated as annotations > > Do you agree? > > I don?t know whether this can (or even should) land in 7.8.1. Do you > care either way? > > Guidance welcome > > Simon > > /Microsoft Research Limited (company number 03369488) is registered in > England and Wales / > > /Registered office is at 21 Station Road, Cambridge, CB1 2FB/ > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From qdunkan at gmail.com Sat Nov 9 21:44:40 2013 From: qdunkan at gmail.com (Evan Laforge) Date: Sat, 9 Nov 2013 13:44:40 -0800 Subject: love for hpc? In-Reply-To: <20131107075545.GA23540@sniper> References: <20131107075545.GA23540@sniper> Message-ID: On Wed, Nov 6, 2013 at 11:55 PM, Roman Cheplyaka wrote: > So Evan's prediction was accurate ;-) There was always the chance someone would say "I'm in the process of making version 2 which is 10x better, just be patient!" :) Ok, I've got a few more things on my TODO list then... From tkn.akio at gmail.com Mon Nov 11 09:18:35 2013 From: tkn.akio at gmail.com (Akio Takano) Date: Mon, 11 Nov 2013 18:18:35 +0900 Subject: Giving function a larger arity Message-ID: Hi, I've been trying to get a certain type of programs compiled into efficient code, but I haven't been able to find a good way to do it, so I'm asking for help. Specifically, it involves a library that defines a newtype whose representation is a function. Attached Lib.hs is an example of such a library. It defines a newtype (Builder), and functions (fromInt, mappend) that deal with it. In user code I want to write a (often-recursive) function that produces a value of the newtype (the 'upto' function in arity.hs is an example). The problem is that I know that the resulting value will be used only once, and I'd like GHC to take advantage of it. In other words, I want the 'upto' function to get compiled into something that takes 4 arguments (Int#, Int#, Addr# and State#), rather than a binary function that returns a lambda. I understand that GHC does not do this by default for a good reason. It avoids potentially calling 'slightlyExpensive' more than once. However I need some way to get the larger arity, because the performance difference can be rather large (for example, this problem can add a lot of boxing to an otherwise allocation-free loop). One of my attempts was to have the library expose a function with which the user can tell GHC that re-computation is okay. Lib.rebuild is such a function, and the 'upto_rebuild' function demonstrates how to use it. Unfortunately this approach only worked when the full-laziness optimization was explicitly disabled. This problem happened many times to me. In particular Reader and State monads often triggered it. I'm using GHC 7.6.3. Any advice? Thank you, Takano Akio -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Lib.hs Type: text/x-haskell Size: 480 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: arity.hs Type: text/x-haskell Size: 518 bytes Desc: not available URL: From simonpj at microsoft.com Mon Nov 11 11:12:03 2013 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon, 11 Nov 2013 11:12:03 +0000 Subject: Giving function a larger arity In-Reply-To: References: Message-ID: <59543203684B2244980D7E4057D5FBC1486731B8@DB3EX14MBXC308.europe.corp.microsoft.com> Strangely enough I've been thinking about eta expansion in the last day or two. It's one of GHC's more delicate corners, because 1. There can be big performance boosts 2. If you push a redex inside a lambda But as you point out (2) may be arbitrarily bad unless you know the lambda is called at most once (is "one-shot"). There is really no good way to declare a lambda to be one-shot right now. As you discovered, full laziness tends to defeat your attempts to do so! (A workaround is to switch off full laziness, but that doesn't feel right.) What is a more general solution? I can think of two. A. Declare one-shot-ness in the type. Something like this: newtype OneShot a = OS a newtype Builder = Builder (OneShot (Ptr ()) -> IO (Ptr ())) plus telling GHC that anything with a OneShot type is a one-shot lambda. B. Declaring one-shot-ness in the terms. Something like ..Builder (\x {-# ONESHOT #-} -> blah)... That would declare this particular lambda to be one-shot, but not any other. Notes * Plan A would require a bit of fiddling to move your values in and out of the OneShot type. And it'd make the terms a bit bigger at compile time. * Plan B is more explicit all the use sites. * Both plans would be vulnerable to user error. I could imagine and analysis that would guarantee that you met the one-shot claim; but it would necessarily be quite conservative. That might or might not be OK * GHC already embodies a version of (A): the "state hack" means that a lambda whose binder is a state token (State# RealWorld#) is treated as one-shot. We have many bug reports describing when this hack makes things bad, but it is such a huge win for more programs that it is on by default. (Your "rebuild" idea might work better with (State# Realorld# -> Builder) rather than (() -> Builder) for that reason.) Simon From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Akio Takano Sent: 11 November 2013 09:19 To: glasgow-haskell-users at haskell.org Subject: Giving function a larger arity Hi, I've been trying to get a certain type of programs compiled into efficient code, but I haven't been able to find a good way to do it, so I'm asking for help. Specifically, it involves a library that defines a newtype whose representation is a function. Attached Lib.hs is an example of such a library. It defines a newtype (Builder), and functions (fromInt, mappend) that deal with it. In user code I want to write a (often-recursive) function that produces a value of the newtype (the 'upto' function in arity.hs is an example). The problem is that I know that the resulting value will be used only once, and I'd like GHC to take advantage of it. In other words, I want the 'upto' function to get compiled into something that takes 4 arguments (Int#, Int#, Addr# and State#), rather than a binary function that returns a lambda. I understand that GHC does not do this by default for a good reason. It avoids potentially calling 'slightlyExpensive' more than once. However I need some way to get the larger arity, because the performance difference can be rather large (for example, this problem can add a lot of boxing to an otherwise allocation-free loop). One of my attempts was to have the library expose a function with which the user can tell GHC that re-computation is okay. Lib.rebuild is such a function, and the 'upto_rebuild' function demonstrates how to use it. Unfortunately this approach only worked when the full-laziness optimization was explicitly disabled. This problem happened many times to me. In particular Reader and State monads often triggered it. I'm using GHC 7.6.3. Any advice? Thank you, Takano Akio -------------- next part -------------- An HTML attachment was scrubbed... URL: From facundo.dominguez at parsci.com Mon Nov 11 16:15:37 2013 From: facundo.dominguez at parsci.com (=?UTF-8?Q?Facundo_Dom=C3=ADnguez?=) Date: Mon, 11 Nov 2013 14:15:37 -0200 Subject: blocking parallel program In-Reply-To: References: <1382222805-sup-3634@javelin> <1382243691-sup-1234@javelin> Message-ID: In case anyone wants to contribute to it, I have submitted a bug report [1]. Best, Facundo [1] https://ghc.haskell.org/trac/ghc/ticket/8521 On Mon, Oct 21, 2013 at 9:03 AM, Facundo Dom?nguez wrote: >> Oh I see; the problem is the GHC RTS is attempting to shut down, >> and in order to do this it needs to grab all of the capabilities. > > Thanks, again. However, the program doesn't seem to be blocking when > the main thread finishes, but rather in the "takeMVar mv1" line. I'm > copying the modified version with a print call that never manages to > print in the console for me. > > btw, I'm using ghc 7.6.3. > > Best, > Facundo > > ----- > > import Control.Concurrent > import Control.Monad > import System.Environment > > main :: IO () > main = do > y <- getArgs > mv0 <- newEmptyMVar > mv1 <- newEmptyMVar > forkIO $ do > takeMVar mv0 > putMVar mv1 () > loop (y == ["yield"]) > putMVar mv0 () > takeMVar mv1 > >>= print > > loop :: Bool -> IO () > loop cooperative = go > where > go = when cooperative yield >> go > > On Sun, Oct 20, 2013 at 2:37 AM, Edward Z. Yang wrote: >> Oh I see; the problem is the GHC RTS is attempting to shut down, >> and in order to do this it needs to grab all of the capabilities. However, >> one of them is in an uninterruptible loop, so the program hangs (e.g. >> if you change the program as follows: >> >> main :: IO () >> main = do >> forkIO $ do >> loop (y == ["yield"]) >> threadDelay 1000 >> ) >> >> With a sufficiently recent version of GHC, if you compile with -fno-omit-yields, >> that should fix the problem. >> >> Edward >> >> Excerpts from Facundo Dom?nguez's message of Sat Oct 19 16:05:15 -0700 2013: >>> Thanks. I just tried that. Unfortunately, it doesn't seem to help. >>> >>> Facundo >>> >>> On Sat, Oct 19, 2013 at 8:47 PM, Edward Z. Yang wrote: >>> > Hello Facundo, >>> > >>> > The reason is that you have compiled the program to be multithreaded, but it >>> > is not running with multiple cores. Compile also with -rtsopts and then >>> > pass +RTS -N2 to the program. >>> > >>> > Excerpts from Facundo Dom?nguez's message of Sat Oct 19 15:19:22 -0700 2013: >>> >> Hello, >>> >> Below is a program that seems to block indefinitely with ghc in a >>> >> multicore machine. This program has a loop that does not produce >>> >> allocations, and I understand that this may grab one of the cores. The >>> >> question is, why can't the other cores take the blocked thread? >>> >> >>> >> The program was compiled with: >>> >> >>> >> $ ghc --make -O -threaded test.hs >>> >> >>> >> and it is run with: >>> >> >>> >> $ ./test >>> >> >>> >> Program text follows. >>> >> >>> >> Thanks, >>> >> Facundo >>> >> >>> >> -------- >>> >> >>> >> import Control.Concurrent >>> >> import Control.Monad >>> >> import System.Environment >>> >> >>> >> main :: IO () >>> >> main = do >>> >> y <- getArgs >>> >> mv0 <- newEmptyMVar >>> >> mv1 <- newEmptyMVar >>> >> forkIO $ do >>> >> takeMVar mv0 >>> >> putMVar mv1 () >>> >> loop (y == ["yield"]) >>> >> putMVar mv0 () >>> >> takeMVar mv1 >>> >> >>> >> loop :: Bool -> IO () >>> >> loop cooperative = go >>> >> where >>> >> go = when cooperative yield >> go >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From jwlato at gmail.com Mon Nov 11 17:28:42 2013 From: jwlato at gmail.com (John Lato) Date: Mon, 11 Nov 2013 11:28:42 -0600 Subject: Giving function a larger arity In-Reply-To: <59543203684B2244980D7E4057D5FBC1486731B8@DB3EX14MBXC308.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC1486731B8@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: Originally I thought Plan B would make more sense, but if Plan A were implemented could this one-shot type annotation be unified with the state hack? I'm envisioning something like RULES, where if the type matches ghc knows it's a one-shot lambda. I think it would be better to not do any analysis and leave this completely up to the user. My intention is to get a mechanism to tell ghc it's okay to recompute something in a lambda, essentially a manual state hack. I seem to recall wanting this, but I don't remember the exact use case. It's possible it was one-shot anyway. John L. On Nov 11, 2013 5:12 AM, "Simon Peyton-Jones" wrote: > Strangely enough I?ve been thinking about eta expansion in the last day > or two. It?s one of GHC?s more delicate corners, because > > 1. There can be big performance boosts > > 2. If you push a redex inside a lambda > > But as you point out (2) may be arbitrarily bad unless you know the lambda > is called at most once (is ?one-shot?). > > > > There is really no good way to declare a lambda to be one-shot right now. > As you discovered, full laziness tends to defeat your attempts to do so! > (A workaround is to switch off full laziness, but that doesn?t feel right.) > > > > What is a more general solution? I can think of two. > > > > A. Declare one-shot-ness in the type. Something like this: > > newtype OneShot a = OS a > > newtype Builder = Builder (OneShot (Ptr ()) -> IO (Ptr ())) > > plus telling GHC that anything with a OneShot type is a > one-shot lambda. > > > > B. Declaring one-shot-ness in the terms. Something like > > ..Builder (\x {-# ONESHOT #-} -> blah)? > > That would declare this particular lambda to be one-shot, > but not any other. > > > > Notes > > ? Plan A would require a bit of fiddling to move your values in > and out of the OneShot type. And it?d make the terms a bit bigger at > compile time. > > ? Plan B is more explicit all the use sites. > > ? Both plans would be vulnerable to user error. I could imagine > and analysis that would guarantee that you met the one-shot claim; but it > would necessarily be quite conservative. That might or might not be OK > > ? GHC already embodies a version of (A): the ?state hack? means > that a lambda whose binder is a state token (State# RealWorld#) is treated > as one-shot. We have many bug reports describing when this hack makes > things bad, but it is such a huge win for more programs that it is on by > default. (Your ?rebuild? idea might work better with (State# Realorld# > -> Builder) rather than (() -> Builder) for that reason.) > > > > Simon > > > > *From:* Glasgow-haskell-users [mailto: > glasgow-haskell-users-bounces at haskell.org] *On Behalf Of *Akio Takano > *Sent:* 11 November 2013 09:19 > *To:* glasgow-haskell-users at haskell.org > *Subject:* Giving function a larger arity > > > > Hi, > > I've been trying to get a certain type of programs compiled into efficient > code, but I haven't been able to find a good way to do it, so I'm asking > for help. > > Specifically, it involves a library that defines a newtype whose > representation is a function. Attached Lib.hs is an example of such a > library. It defines a newtype (Builder), and functions (fromInt, mappend) > that deal with it. > > In user code I want to write a (often-recursive) function that produces a > value of the newtype (the 'upto' function in arity.hs is an example). The > problem is that I know that the resulting value will be used only once, and > I'd like GHC to take advantage of it. In other words, I want the 'upto' > function to get compiled into something that takes 4 arguments (Int#, Int#, > Addr# and State#), rather than a binary function that returns a lambda. > > I understand that GHC does not do this by default for a good reason. It > avoids potentially calling 'slightlyExpensive' more than once. However I > need some way to get the larger arity, because the performance difference > can be rather large (for example, this problem can add a lot of boxing to > an otherwise allocation-free loop). > > One of my attempts was to have the library expose a function with which > the user can tell GHC that re-computation is okay. Lib.rebuild is such a > function, and the 'upto_rebuild' function demonstrates how to use it. > Unfortunately this approach only worked when the full-laziness optimization > was explicitly disabled. > > This problem happened many times to me. In particular Reader and State > monads often triggered it. > > I'm using GHC 7.6.3. > > Any advice? > > Thank you, > Takano Akio > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Nov 11 21:29:13 2013 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon, 11 Nov 2013 21:29:13 +0000 Subject: Giving function a larger arity In-Reply-To: References: <59543203684B2244980D7E4057D5FBC1486731B8@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: <59543203684B2244980D7E4057D5FBC148676935@DB3EX14MBXC308.europe.corp.microsoft.com> Well, Plan A is indeed an extended version of the "state hack". Instead of just (State# RealWorld#) being magically considered one-shot, we'd also add (OneShot t). Simon From: John Lato [mailto:jwlato at gmail.com] Sent: 11 November 2013 17:29 To: Simon Peyton-Jones Cc: glasgow-haskell-users at haskell.org; Akio Takano Subject: RE: Giving function a larger arity Originally I thought Plan B would make more sense, but if Plan A were implemented could this one-shot type annotation be unified with the state hack? I'm envisioning something like RULES, where if the type matches ghc knows it's a one-shot lambda. I think it would be better to not do any analysis and leave this completely up to the user. My intention is to get a mechanism to tell ghc it's okay to recompute something in a lambda, essentially a manual state hack. I seem to recall wanting this, but I don't remember the exact use case. It's possible it was one-shot anyway. John L. On Nov 11, 2013 5:12 AM, "Simon Peyton-Jones" > wrote: Strangely enough I've been thinking about eta expansion in the last day or two. It's one of GHC's more delicate corners, because 1. There can be big performance boosts 2. If you push a redex inside a lambda But as you point out (2) may be arbitrarily bad unless you know the lambda is called at most once (is "one-shot"). There is really no good way to declare a lambda to be one-shot right now. As you discovered, full laziness tends to defeat your attempts to do so! (A workaround is to switch off full laziness, but that doesn't feel right.) What is a more general solution? I can think of two. A. Declare one-shot-ness in the type. Something like this: newtype OneShot a = OS a newtype Builder = Builder (OneShot (Ptr ()) -> IO (Ptr ())) plus telling GHC that anything with a OneShot type is a one-shot lambda. B. Declaring one-shot-ness in the terms. Something like ..Builder (\x {-# ONESHOT #-} -> blah)... That would declare this particular lambda to be one-shot, but not any other. Notes * Plan A would require a bit of fiddling to move your values in and out of the OneShot type. And it'd make the terms a bit bigger at compile time. * Plan B is more explicit all the use sites. * Both plans would be vulnerable to user error. I could imagine and analysis that would guarantee that you met the one-shot claim; but it would necessarily be quite conservative. That might or might not be OK * GHC already embodies a version of (A): the "state hack" means that a lambda whose binder is a state token (State# RealWorld#) is treated as one-shot. We have many bug reports describing when this hack makes things bad, but it is such a huge win for more programs that it is on by default. (Your "rebuild" idea might work better with (State# Realorld# -> Builder) rather than (() -> Builder) for that reason.) Simon From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Akio Takano Sent: 11 November 2013 09:19 To: glasgow-haskell-users at haskell.org Subject: Giving function a larger arity Hi, I've been trying to get a certain type of programs compiled into efficient code, but I haven't been able to find a good way to do it, so I'm asking for help. Specifically, it involves a library that defines a newtype whose representation is a function. Attached Lib.hs is an example of such a library. It defines a newtype (Builder), and functions (fromInt, mappend) that deal with it. In user code I want to write a (often-recursive) function that produces a value of the newtype (the 'upto' function in arity.hs is an example). The problem is that I know that the resulting value will be used only once, and I'd like GHC to take advantage of it. In other words, I want the 'upto' function to get compiled into something that takes 4 arguments (Int#, Int#, Addr# and State#), rather than a binary function that returns a lambda. I understand that GHC does not do this by default for a good reason. It avoids potentially calling 'slightlyExpensive' more than once. However I need some way to get the larger arity, because the performance difference can be rather large (for example, this problem can add a lot of boxing to an otherwise allocation-free loop). One of my attempts was to have the library expose a function with which the user can tell GHC that re-computation is okay. Lib.rebuild is such a function, and the 'upto_rebuild' function demonstrates how to use it. Unfortunately this approach only worked when the full-laziness optimization was explicitly disabled. This problem happened many times to me. In particular Reader and State monads often triggered it. I'm using GHC 7.6.3. Any advice? Thank you, Takano Akio _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users at haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Mon Nov 11 21:38:46 2013 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 11 Nov 2013 16:38:46 -0500 Subject: Giving function a larger arity In-Reply-To: <59543203684B2244980D7E4057D5FBC148676935@DB3EX14MBXC308.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC1486731B8@DB3EX14MBXC308.europe.corp.microsoft.com> <59543203684B2244980D7E4057D5FBC148676935@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: and this would be a way of hinting / communicating that a lambda will be used at most once? On Mon, Nov 11, 2013 at 4:29 PM, Simon Peyton-Jones wrote: > Well, Plan A is indeed an extended version of the ?state hack?. Instead > of just (State# RealWorld#) being magically considered one-shot, we?d also > add (OneShot t). > > > > Simon > > > > *From:* John Lato [mailto:jwlato at gmail.com] > *Sent:* 11 November 2013 17:29 > *To:* Simon Peyton-Jones > *Cc:* glasgow-haskell-users at haskell.org; Akio Takano > *Subject:* RE: Giving function a larger arity > > > > Originally I thought Plan B would make more sense, but if Plan A were > implemented could this one-shot type annotation be unified with the state > hack? I'm envisioning something like RULES, where if the type matches ghc > knows it's a one-shot lambda. > > I think it would be better to not do any analysis and leave this > completely up to the user. My intention is to get a mechanism to tell ghc > it's okay to recompute something in a lambda, essentially a manual state > hack. I seem to recall wanting this, but I don't remember the exact use > case. It's possible it was one-shot anyway. > > John L. > > On Nov 11, 2013 5:12 AM, "Simon Peyton-Jones" > wrote: > > Strangely enough I?ve been thinking about eta expansion in the last day > or two. It?s one of GHC?s more delicate corners, because > > 1. There can be big performance boosts > > 2. If you push a redex inside a lambda > > But as you point out (2) may be arbitrarily bad unless you know the lambda > is called at most once (is ?one-shot?). > > > > There is really no good way to declare a lambda to be one-shot right now. > As you discovered, full laziness tends to defeat your attempts to do so! > (A workaround is to switch off full laziness, but that doesn?t feel right.) > > > > What is a more general solution? I can think of two. > > > > A. Declare one-shot-ness in the type. Something like this: > > newtype OneShot a = OS a > > newtype Builder = Builder (OneShot (Ptr ()) -> IO (Ptr ())) > > plus telling GHC that anything with a OneShot type is a > one-shot lambda. > > > > B. Declaring one-shot-ness in the terms. Something like > > ..Builder (\x {-# ONESHOT #-} -> blah)? > > That would declare this particular lambda to be one-shot, > but not any other. > > > > Notes > > ? Plan A would require a bit of fiddling to move your values in > and out of the OneShot type. And it?d make the terms a bit bigger at > compile time. > > ? Plan B is more explicit all the use sites. > > ? Both plans would be vulnerable to user error. I could imagine > and analysis that would guarantee that you met the one-shot claim; but it > would necessarily be quite conservative. That might or might not be OK > > ? GHC already embodies a version of (A): the ?state hack? means > that a lambda whose binder is a state token (State# RealWorld#) is treated > as one-shot. We have many bug reports describing when this hack makes > things bad, but it is such a huge win for more programs that it is on by > default. (Your ?rebuild? idea might work better with (State# Realorld# > -> Builder) rather than (() -> Builder) for that reason.) > > > > Simon > > > > *From:* Glasgow-haskell-users [mailto: > glasgow-haskell-users-bounces at haskell.org] *On Behalf Of *Akio Takano > *Sent:* 11 November 2013 09:19 > *To:* glasgow-haskell-users at haskell.org > *Subject:* Giving function a larger arity > > > > Hi, > > I've been trying to get a certain type of programs compiled into efficient > code, but I haven't been able to find a good way to do it, so I'm asking > for help. > > Specifically, it involves a library that defines a newtype whose > representation is a function. Attached Lib.hs is an example of such a > library. It defines a newtype (Builder), and functions (fromInt, mappend) > that deal with it. > > In user code I want to write a (often-recursive) function that produces a > value of the newtype (the 'upto' function in arity.hs is an example). The > problem is that I know that the resulting value will be used only once, and > I'd like GHC to take advantage of it. In other words, I want the 'upto' > function to get compiled into something that takes 4 arguments (Int#, Int#, > Addr# and State#), rather than a binary function that returns a lambda. > > I understand that GHC does not do this by default for a good reason. It > avoids potentially calling 'slightlyExpensive' more than once. However I > need some way to get the larger arity, because the performance difference > can be rather large (for example, this problem can add a lot of boxing to > an otherwise allocation-free loop). > > One of my attempts was to have the library expose a function with which > the user can tell GHC that re-computation is okay. Lib.rebuild is such a > function, and the 'upto_rebuild' function demonstrates how to use it. > Unfortunately this approach only worked when the full-laziness optimization > was explicitly disabled. > > This problem happened many times to me. In particular Reader and State > monads often triggered it. > > I'm using GHC 7.6.3. > > Any advice? > > Thank you, > Takano Akio > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwlato at gmail.com Tue Nov 12 00:11:48 2013 From: jwlato at gmail.com (John Lato) Date: Mon, 11 Nov 2013 18:11:48 -0600 Subject: Giving function a larger arity In-Reply-To: <59543203684B2244980D7E4057D5FBC148676935@DB3EX14MBXC308.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC1486731B8@DB3EX14MBXC308.europe.corp.microsoft.com> <59543203684B2244980D7E4057D5FBC148676935@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: Yes, that's what I meant. I was thinking that from an implementation perspective, it would be nice if all the one-shot hacks were in a single place, and if plan A facilitated that it would be a good reason to support that approach. But I suppose checking an annotation is no harder than checking a type, so it's probably irrelevant. On Mon, Nov 11, 2013 at 3:29 PM, Simon Peyton-Jones wrote: > Well, Plan A is indeed an extended version of the ?state hack?. Instead > of just (State# RealWorld#) being magically considered one-shot, we?d also > add (OneShot t). > > > > Simon > > > > *From:* John Lato [mailto:jwlato at gmail.com] > *Sent:* 11 November 2013 17:29 > *To:* Simon Peyton-Jones > *Cc:* glasgow-haskell-users at haskell.org; Akio Takano > *Subject:* RE: Giving function a larger arity > > > > Originally I thought Plan B would make more sense, but if Plan A were > implemented could this one-shot type annotation be unified with the state > hack? I'm envisioning something like RULES, where if the type matches ghc > knows it's a one-shot lambda. > > I think it would be better to not do any analysis and leave this > completely up to the user. My intention is to get a mechanism to tell ghc > it's okay to recompute something in a lambda, essentially a manual state > hack. I seem to recall wanting this, but I don't remember the exact use > case. It's possible it was one-shot anyway. > > John L. > > On Nov 11, 2013 5:12 AM, "Simon Peyton-Jones" > wrote: > > Strangely enough I?ve been thinking about eta expansion in the last day > or two. It?s one of GHC?s more delicate corners, because > > 1. There can be big performance boosts > > 2. If you push a redex inside a lambda > > But as you point out (2) may be arbitrarily bad unless you know the lambda > is called at most once (is ?one-shot?). > > > > There is really no good way to declare a lambda to be one-shot right now. > As you discovered, full laziness tends to defeat your attempts to do so! > (A workaround is to switch off full laziness, but that doesn?t feel right.) > > > > What is a more general solution? I can think of two. > > > > A. Declare one-shot-ness in the type. Something like this: > > newtype OneShot a = OS a > > newtype Builder = Builder (OneShot (Ptr ()) -> IO (Ptr ())) > > plus telling GHC that anything with a OneShot type is a > one-shot lambda. > > > > B. Declaring one-shot-ness in the terms. Something like > > ..Builder (\x {-# ONESHOT #-} -> blah)? > > That would declare this particular lambda to be one-shot, > but not any other. > > > > Notes > > ? Plan A would require a bit of fiddling to move your values in > and out of the OneShot type. And it?d make the terms a bit bigger at > compile time. > > ? Plan B is more explicit all the use sites. > > ? Both plans would be vulnerable to user error. I could imagine > and analysis that would guarantee that you met the one-shot claim; but it > would necessarily be quite conservative. That might or might not be OK > > ? GHC already embodies a version of (A): the ?state hack? means > that a lambda whose binder is a state token (State# RealWorld#) is treated > as one-shot. We have many bug reports describing when this hack makes > things bad, but it is such a huge win for more programs that it is on by > default. (Your ?rebuild? idea might work better with (State# Realorld# > -> Builder) rather than (() -> Builder) for that reason.) > > > > Simon > > > > *From:* Glasgow-haskell-users [mailto: > glasgow-haskell-users-bounces at haskell.org] *On Behalf Of *Akio Takano > *Sent:* 11 November 2013 09:19 > *To:* glasgow-haskell-users at haskell.org > *Subject:* Giving function a larger arity > > > > Hi, > > I've been trying to get a certain type of programs compiled into efficient > code, but I haven't been able to find a good way to do it, so I'm asking > for help. > > Specifically, it involves a library that defines a newtype whose > representation is a function. Attached Lib.hs is an example of such a > library. It defines a newtype (Builder), and functions (fromInt, mappend) > that deal with it. > > In user code I want to write a (often-recursive) function that produces a > value of the newtype (the 'upto' function in arity.hs is an example). The > problem is that I know that the resulting value will be used only once, and > I'd like GHC to take advantage of it. In other words, I want the 'upto' > function to get compiled into something that takes 4 arguments (Int#, Int#, > Addr# and State#), rather than a binary function that returns a lambda. > > I understand that GHC does not do this by default for a good reason. It > avoids potentially calling 'slightlyExpensive' more than once. However I > need some way to get the larger arity, because the performance difference > can be rather large (for example, this problem can add a lot of boxing to > an otherwise allocation-free loop). > > One of my attempts was to have the library expose a function with which > the user can tell GHC that re-computation is okay. Lib.rebuild is such a > function, and the 'upto_rebuild' function demonstrates how to use it. > Unfortunately this approach only worked when the full-laziness optimization > was explicitly disabled. > > This problem happened many times to me. In particular Reader and State > monads often triggered it. > > I'm using GHC 7.6.3. > > Any advice? > > Thank you, > Takano Akio > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Nov 12 08:36:31 2013 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue, 12 Nov 2013 08:36:31 +0000 Subject: Giving function a larger arity In-Reply-To: References: <59543203684B2244980D7E4057D5FBC1486731B8@DB3EX14MBXC308.europe.corp.microsoft.com> <59543203684B2244980D7E4057D5FBC148676935@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: <59543203684B2244980D7E4057D5FBC148676E5A@DB3EX14MBXC308.europe.corp.microsoft.com> There is a difference between plan A and B. For example, if f :: (OneShot a -> b) -> [a] -> [b] then EVERY function passed to f would have to be one-shot (Plan A). But under plan B you could have two calls ...f (\x. blah)..... f (\y{-#ONESHOT#-}. blah2).... and only the second would be a one-shot lambda. So if anything plan B seems more flexible. Simon From: John Lato [mailto:jwlato at gmail.com] Sent: 12 November 2013 00:12 To: Simon Peyton-Jones Cc: glasgow-haskell-users at haskell.org; Akio Takano Subject: Re: Giving function a larger arity Yes, that's what I meant. I was thinking that from an implementation perspective, it would be nice if all the one-shot hacks were in a single place, and if plan A facilitated that it would be a good reason to support that approach. But I suppose checking an annotation is no harder than checking a type, so it's probably irrelevant. On Mon, Nov 11, 2013 at 3:29 PM, Simon Peyton-Jones > wrote: Well, Plan A is indeed an extended version of the "state hack". Instead of just (State# RealWorld#) being magically considered one-shot, we'd also add (OneShot t). Simon From: John Lato [mailto:jwlato at gmail.com] Sent: 11 November 2013 17:29 To: Simon Peyton-Jones Cc: glasgow-haskell-users at haskell.org; Akio Takano Subject: RE: Giving function a larger arity Originally I thought Plan B would make more sense, but if Plan A were implemented could this one-shot type annotation be unified with the state hack? I'm envisioning something like RULES, where if the type matches ghc knows it's a one-shot lambda. I think it would be better to not do any analysis and leave this completely up to the user. My intention is to get a mechanism to tell ghc it's okay to recompute something in a lambda, essentially a manual state hack. I seem to recall wanting this, but I don't remember the exact use case. It's possible it was one-shot anyway. John L. On Nov 11, 2013 5:12 AM, "Simon Peyton-Jones" > wrote: Strangely enough I've been thinking about eta expansion in the last day or two. It's one of GHC's more delicate corners, because 1. There can be big performance boosts 2. If you push a redex inside a lambda But as you point out (2) may be arbitrarily bad unless you know the lambda is called at most once (is "one-shot"). There is really no good way to declare a lambda to be one-shot right now. As you discovered, full laziness tends to defeat your attempts to do so! (A workaround is to switch off full laziness, but that doesn't feel right.) What is a more general solution? I can think of two. A. Declare one-shot-ness in the type. Something like this: newtype OneShot a = OS a newtype Builder = Builder (OneShot (Ptr ()) -> IO (Ptr ())) plus telling GHC that anything with a OneShot type is a one-shot lambda. B. Declaring one-shot-ness in the terms. Something like ..Builder (\x {-# ONESHOT #-} -> blah)... That would declare this particular lambda to be one-shot, but not any other. Notes * Plan A would require a bit of fiddling to move your values in and out of the OneShot type. And it'd make the terms a bit bigger at compile time. * Plan B is more explicit all the use sites. * Both plans would be vulnerable to user error. I could imagine and analysis that would guarantee that you met the one-shot claim; but it would necessarily be quite conservative. That might or might not be OK * GHC already embodies a version of (A): the "state hack" means that a lambda whose binder is a state token (State# RealWorld#) is treated as one-shot. We have many bug reports describing when this hack makes things bad, but it is such a huge win for more programs that it is on by default. (Your "rebuild" idea might work better with (State# Realorld# -> Builder) rather than (() -> Builder) for that reason.) Simon From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Akio Takano Sent: 11 November 2013 09:19 To: glasgow-haskell-users at haskell.org Subject: Giving function a larger arity Hi, I've been trying to get a certain type of programs compiled into efficient code, but I haven't been able to find a good way to do it, so I'm asking for help. Specifically, it involves a library that defines a newtype whose representation is a function. Attached Lib.hs is an example of such a library. It defines a newtype (Builder), and functions (fromInt, mappend) that deal with it. In user code I want to write a (often-recursive) function that produces a value of the newtype (the 'upto' function in arity.hs is an example). The problem is that I know that the resulting value will be used only once, and I'd like GHC to take advantage of it. In other words, I want the 'upto' function to get compiled into something that takes 4 arguments (Int#, Int#, Addr# and State#), rather than a binary function that returns a lambda. I understand that GHC does not do this by default for a good reason. It avoids potentially calling 'slightlyExpensive' more than once. However I need some way to get the larger arity, because the performance difference can be rather large (for example, this problem can add a lot of boxing to an otherwise allocation-free loop). One of my attempts was to have the library expose a function with which the user can tell GHC that re-computation is okay. Lib.rebuild is such a function, and the 'upto_rebuild' function demonstrates how to use it. Unfortunately this approach only worked when the full-laziness optimization was explicitly disabled. This problem happened many times to me. In particular Reader and State monads often triggered it. I'm using GHC 7.6.3. Any advice? Thank you, Takano Akio _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users at haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Tue Nov 12 09:18:38 2013 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 12 Nov 2013 10:18:38 +0100 Subject: Giving function a larger arity In-Reply-To: <59543203684B2244980D7E4057D5FBC148676E5A@DB3EX14MBXC308.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC1486731B8@DB3EX14MBXC308.europe.corp.microsoft.com> <59543203684B2244980D7E4057D5FBC148676935@DB3EX14MBXC308.europe.corp.microsoft.com> <59543203684B2244980D7E4057D5FBC148676E5A@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: And plan 2 doesn't require a magic data type. :) On Tue, Nov 12, 2013 at 9:36 AM, Simon Peyton-Jones wrote: > There is a difference between plan A and B. For example, if > > f :: (OneShot a -> b) -> [a] -> [b] > > then EVERY function passed to f would have to be one-shot (Plan A). But > under plan B you could have two calls > > > > ?f (\x. blah)?.. f (\y{-#ONESHOT#-}. blah2)?. > > > > and only the second would be a one-shot lambda. > > > > So if anything plan B seems more flexible. > > > > Simon > > > > > > *From:* John Lato [mailto:jwlato at gmail.com] > *Sent:* 12 November 2013 00:12 > > *To:* Simon Peyton-Jones > *Cc:* glasgow-haskell-users at haskell.org; Akio Takano > *Subject:* Re: Giving function a larger arity > > > > Yes, that's what I meant. I was thinking that from an implementation > perspective, it would be nice if all the one-shot hacks were in a single > place, and if plan A facilitated that it would be a good reason to support > that approach. But I suppose checking an annotation is no harder than > checking a type, so it's probably irrelevant. > > > > On Mon, Nov 11, 2013 at 3:29 PM, Simon Peyton-Jones > wrote: > > Well, Plan A is indeed an extended version of the ?state hack?. Instead > of just (State# RealWorld#) being magically considered one-shot, we?d also > add (OneShot t). > > > > Simon > > > > *From:* John Lato [mailto:jwlato at gmail.com] > > *Sent:* 11 November 2013 17:29 > > *To:* Simon Peyton-Jones > *Cc:* glasgow-haskell-users at haskell.org; Akio Takano > *Subject:* RE: Giving function a larger arity > > > > Originally I thought Plan B would make more sense, but if Plan A were > implemented could this one-shot type annotation be unified with the state > hack? I'm envisioning something like RULES, where if the type matches ghc > knows it's a one-shot lambda. > > I think it would be better to not do any analysis and leave this > completely up to the user. My intention is to get a mechanism to tell ghc > it's okay to recompute something in a lambda, essentially a manual state > hack. I seem to recall wanting this, but I don't remember the exact use > case. It's possible it was one-shot anyway. > > John L. > > On Nov 11, 2013 5:12 AM, "Simon Peyton-Jones" > wrote: > > Strangely enough I?ve been thinking about eta expansion in the last day > or two. It?s one of GHC?s more delicate corners, because > > 1. There can be big performance boosts > > 2. If you push a redex inside a lambda > > But as you point out (2) may be arbitrarily bad unless you know the lambda > is called at most once (is ?one-shot?). > > > > There is really no good way to declare a lambda to be one-shot right now. > As you discovered, full laziness tends to defeat your attempts to do so! > (A workaround is to switch off full laziness, but that doesn?t feel right.) > > > > What is a more general solution? I can think of two. > > > > A. Declare one-shot-ness in the type. Something like this: > > newtype OneShot a = OS a > > newtype Builder = Builder (OneShot (Ptr ()) -> IO (Ptr ())) > > plus telling GHC that anything with a OneShot type is a > one-shot lambda. > > > > B. Declaring one-shot-ness in the terms. Something like > > ..Builder (\x {-# ONESHOT #-} -> blah)? > > That would declare this particular lambda to be one-shot, > but not any other. > > > > Notes > > ? Plan A would require a bit of fiddling to move your values in > and out of the OneShot type. And it?d make the terms a bit bigger at > compile time. > > ? Plan B is more explicit all the use sites. > > ? Both plans would be vulnerable to user error. I could imagine > and analysis that would guarantee that you met the one-shot claim; but it > would necessarily be quite conservative. That might or might not be OK > > ? GHC already embodies a version of (A): the ?state hack? means > that a lambda whose binder is a state token (State# RealWorld#) is treated > as one-shot. We have many bug reports describing when this hack makes > things bad, but it is such a huge win for more programs that it is on by > default. (Your ?rebuild? idea might work better with (State# Realorld# > -> Builder) rather than (() -> Builder) for that reason.) > > > > Simon > > > > *From:* Glasgow-haskell-users [mailto: > glasgow-haskell-users-bounces at haskell.org] *On Behalf Of *Akio Takano > *Sent:* 11 November 2013 09:19 > *To:* glasgow-haskell-users at haskell.org > *Subject:* Giving function a larger arity > > > > Hi, > > I've been trying to get a certain type of programs compiled into efficient > code, but I haven't been able to find a good way to do it, so I'm asking > for help. > > Specifically, it involves a library that defines a newtype whose > representation is a function. Attached Lib.hs is an example of such a > library. It defines a newtype (Builder), and functions (fromInt, mappend) > that deal with it. > > In user code I want to write a (often-recursive) function that produces a > value of the newtype (the 'upto' function in arity.hs is an example). The > problem is that I know that the resulting value will be used only once, and > I'd like GHC to take advantage of it. In other words, I want the 'upto' > function to get compiled into something that takes 4 arguments (Int#, Int#, > Addr# and State#), rather than a binary function that returns a lambda. > > I understand that GHC does not do this by default for a good reason. It > avoids potentially calling 'slightlyExpensive' more than once. However I > need some way to get the larger arity, because the performance difference > can be rather large (for example, this problem can add a lot of boxing to > an otherwise allocation-free loop). > > One of my attempts was to have the library expose a function with which > the user can tell GHC that re-computation is okay. Lib.rebuild is such a > function, and the 'upto_rebuild' function demonstrates how to use it. > Unfortunately this approach only worked when the full-laziness optimization > was explicitly disabled. > > This problem happened many times to me. In particular Reader and State > monads often triggered it. > > I'm using GHC 7.6.3. > > Any advice? > > Thank you, > Takano Akio > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.r.ford at gmail.com Tue Nov 12 19:53:55 2013 From: alexander.r.ford at gmail.com (Alex Ford) Date: Tue, 12 Nov 2013 19:53:55 +0000 Subject: Adding new library dependencies to GHC Message-ID: Hi, I've made some changes to the LLVM backend of GHC to make it use llvm-general to output bitcode rather than pretty printing human readable LLVM assembly. However, I've been having trouble linking the required libraries (llvm-general and its transitive dependencies). The steps I've taken so far are to put the required libraries in the build tree under libraries, and added them to the packages file, to PACKAGES_STAGE0 and PACKAGES_STAGE1 in ghc.mk, and to the build depends section in compiler/ ghc.cabal.in. The build fails in phase 1 when trying to link utf8-string (a dependency of llvm-general) during the build of llvm-general, with: Loading package utf8-string-0.3.7 ... : can't load .so/.DLL for: libHSutf8-string-0.3.7.so (libHSutf8-string-0.3.7.so: cannot open shared object file: No such file or directory) The problem seems to be that with pre-existing library dependencies, the system-wide libraries at /usr/lib/ghc-7.6.3// are pulled in, whereas with the new dependencies, versions within the build tree (e.g. at libraries/utf8-string/dist-install/build/) are tried instead, despite these new libraries being installed globally within the same parent directory and being listed by ghc-pkg (no errors upon ghc-pkg check either). For example, in compiler/stage1/package-data.mk, compiler_stage1_DEP_LIB_DIRS_SEARCHPATH specifies /usr/lib/ghc-7.6.3/bytestring-0.10.0.2, and bytestring links successfully, but for utf8-string specifies /libraries/utf8-string/dist-boot/build. I've read through the documentation on libraries for GHC but can't figure out how to make this work. Could anyone suggest how I could go about fixing this? As a slightly related question, llvm-general depends on template-haskell. Will this cause problems when building GHC normally, since the stage 1 compiler does not support TH? If so is there any way to compile stage 2 directly using the stage 0 compiler? Many thanks, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From tkn.akio at gmail.com Tue Nov 12 23:51:16 2013 From: tkn.akio at gmail.com (Akio Takano) Date: Wed, 13 Nov 2013 08:51:16 +0900 Subject: Giving function a larger arity In-Reply-To: <59543203684B2244980D7E4057D5FBC1486731B8@DB3EX14MBXC308.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC1486731B8@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: Using State# RealWorld for rebuild worked fine for the particular problem I had. Thank you very much! I'd appreciate either solution because it would make it possible to solve the issue without much change in the user code. A few months ago I tried something similar to the approach B (I used a built-in rule rather than a pragma), in order to re-implement foldl' in terms of foldr. It didn't work very well, but I don't remember what the problem was. Sadly I don't have access to the patch right now. Probably I made a mistake somewhere. On Mon, Nov 11, 2013 at 8:12 PM, Simon Peyton-Jones wrote: > Strangely enough I?ve been thinking about eta expansion in the last day > or two. It?s one of GHC?s more delicate corners, because > > 1. There can be big performance boosts > > 2. If you push a redex inside a lambda > > But as you point out (2) may be arbitrarily bad unless you know the lambda > is called at most once (is ?one-shot?). > > > > There is really no good way to declare a lambda to be one-shot right now. > As you discovered, full laziness tends to defeat your attempts to do so! > (A workaround is to switch off full laziness, but that doesn?t feel right.) > > > > What is a more general solution? I can think of two. > > > > A. Declare one-shot-ness in the type. Something like this: > > newtype OneShot a = OS a > > newtype Builder = Builder (OneShot (Ptr ()) -> IO (Ptr ())) > > plus telling GHC that anything with a OneShot type is a > one-shot lambda. > > > > B. Declaring one-shot-ness in the terms. Something like > > ..Builder (\x {-# ONESHOT #-} -> blah)? > > That would declare this particular lambda to be one-shot, > but not any other. > > > > Notes > > ? Plan A would require a bit of fiddling to move your values in > and out of the OneShot type. And it?d make the terms a bit bigger at > compile time. > > ? Plan B is more explicit all the use sites. > > ? Both plans would be vulnerable to user error. I could imagine > and analysis that would guarantee that you met the one-shot claim; but it > would necessarily be quite conservative. That might or might not be OK > > ? GHC already embodies a version of (A): the ?state hack? means > that a lambda whose binder is a state token (State# RealWorld#) is treated > as one-shot. We have many bug reports describing when this hack makes > things bad, but it is such a huge win for more programs that it is on by > default. (Your ?rebuild? idea might work better with (State# Realorld# > -> Builder) rather than (() -> Builder) for that reason.) > > > > Simon > > > > *From:* Glasgow-haskell-users [mailto: > glasgow-haskell-users-bounces at haskell.org] *On Behalf Of *Akio Takano > *Sent:* 11 November 2013 09:19 > *To:* glasgow-haskell-users at haskell.org > *Subject:* Giving function a larger arity > > > > Hi, > > I've been trying to get a certain type of programs compiled into efficient > code, but I haven't been able to find a good way to do it, so I'm asking > for help. > > Specifically, it involves a library that defines a newtype whose > representation is a function. Attached Lib.hs is an example of such a > library. It defines a newtype (Builder), and functions (fromInt, mappend) > that deal with it. > > In user code I want to write a (often-recursive) function that produces a > value of the newtype (the 'upto' function in arity.hs is an example). The > problem is that I know that the resulting value will be used only once, and > I'd like GHC to take advantage of it. In other words, I want the 'upto' > function to get compiled into something that takes 4 arguments (Int#, Int#, > Addr# and State#), rather than a binary function that returns a lambda. > > I understand that GHC does not do this by default for a good reason. It > avoids potentially calling 'slightlyExpensive' more than once. However I > need some way to get the larger arity, because the performance difference > can be rather large (for example, this problem can add a lot of boxing to > an otherwise allocation-free loop). > > One of my attempts was to have the library expose a function with which > the user can tell GHC that re-computation is okay. Lib.rebuild is such a > function, and the 'upto_rebuild' function demonstrates how to use it. > Unfortunately this approach only worked when the full-laziness optimization > was explicitly disabled. > > This problem happened many times to me. In particular Reader and State > monads often triggered it. > > I'm using GHC 7.6.3. > > Any advice? > > Thank you, > Takano Akio > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Wed Nov 13 02:35:02 2013 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 12 Nov 2013 21:35:02 -0500 Subject: Adding new library dependencies to GHC In-Reply-To: References: Message-ID: Hey Alex, very very cool! a few thoughts: ghc stage1 has no GHCI, and thus can't build / use a lib that has template haskell. LLVM-General uses template haskell pretty heavily to generate the FFI code! see https://github.com/bscarlet/llvm-general/blob/master/llvm-general/src/LLVM/General/Internal/FFI/Builder.hs#L66 example and https://github.com/bscarlet/llvm-general/blob/master/llvm-general/src/LLVM/General/Internal/FFI/Constant.hs#L89 for another so your choices are: figure out how to support TH in stage 1 ghc, OR use llvm-general-pure, and cope with just having llvm pretty printing and parsing. Alternatively, you could treat the "llvm-general" way as being an alternative to the -fasm and -fllvm backends, and have it only be built / supported in the stage2 backend. point being: start with getting -flllvm working just using llvm-general-pure then once you've got that working, having an llvm alternative that can ghc can enable in stage2 (when ghci/th is a thing) can be made to work. either way, very cool! it gives a path towards bundling llvm with ghc, or at least is a decent experiment towards that. one thing you may want to consider is how to remove the TH deps from llvm general. This would make it possible use it in stage1 GHC, which would make it much more likely to be actually merged into GHC proper. again, props for getting this experimentation started! -Carter On Tue, Nov 12, 2013 at 2:53 PM, Alex Ford wrote: > Hi, > > I've made some changes to the LLVM backend of GHC to make it use > llvm-general to output bitcode rather than pretty printing human readable > LLVM assembly. However, I've been having trouble linking the required > libraries (llvm-general and its transitive dependencies). The steps I've > taken so far are to put the required libraries in the build tree under > libraries, and added them to the packages file, to PACKAGES_STAGE0 and > PACKAGES_STAGE1 in ghc.mk, and to the build depends section in compiler/ > ghc.cabal.in. > > The build fails in phase 1 when trying to link utf8-string (a dependency > of llvm-general) during the build of llvm-general, with: > Loading package utf8-string-0.3.7 ... : can't load .so/.DLL > for: libHSutf8-string-0.3.7.so (libHSutf8-string-0.3.7.so: cannot open > shared object file: No such file or directory) > > The problem seems to be that with pre-existing library dependencies, the > system-wide libraries at /usr/lib/ghc-7.6.3// are pulled in, > whereas with the new dependencies, versions within the build tree (e.g. at > libraries/utf8-string/dist-install/build/) are tried instead, despite these > new libraries being installed globally within the same parent directory and > being listed by ghc-pkg (no errors upon ghc-pkg check either). > > For example, in compiler/stage1/package-data.mk, > compiler_stage1_DEP_LIB_DIRS_SEARCHPATH > specifies /usr/lib/ghc-7.6.3/bytestring-0.10.0.2, and bytestring links > successfully, but for utf8-string specifies > /libraries/utf8-string/dist-boot/build. > > I've read through the documentation on libraries for GHC but can't figure > out how to make this work. Could anyone suggest how I could go about fixing > this? > > As a slightly related question, llvm-general depends on template-haskell. > Will this cause problems when building GHC normally, since the stage 1 > compiler does not support TH? If so is there any way to compile stage 2 > directly using the stage 0 compiler? > > Many thanks, > Alex > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Wed Nov 13 10:29:46 2013 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 13 Nov 2013 10:29:46 +0000 Subject: love for hpc? In-Reply-To: References: Message-ID: <5283549A.1010305@gmail.com> On 07/11/13 05:03, Evan Laforge wrote: > Is anyone out there using HPC? It seems like it was gotten into a > more or less working if not ideal state, and then abandoned. > > Things I've noticed lately: > > The GHC runtime just quits on the spot if there's already a tix file. > This bit me when I was parallelizing tests. It's also completely > unsafe when run concurrently, mostly it just overwrites the file, > sometimes it quits. Sure to cause headaches for someone trying to > parallelize tests. > > You can't change the name of the output tix file, so I worked around > by hardlinking the binary to a bunch of new ones, and then doing 'hpc > sum' on the results. > > The hpc command is super slow. It might have to do with it doing its > parsing with Prelude's 'read', and it certainly doesn't help the error > msgs. > > And the whole thing is generally minimally documented. > > I can already predict the answer will be "yes, HPC could use some > love, roll up your sleeves and welcome!" It does look like it could > be improved a lot with just a bit of effort, but that would be a yak > too far for me, at the moment. I'm presently just curious if anyone > else out there is using it, and if they feel like it could do with a > bit of polishing. I think the core functionality of HPC is working pretty well, I gave it an overhaul when I combined the internal mechanisms used by HPC, Profiling and the GHCi debugger. The surrounding tooling and documentation, as you say, could do with some love. I think this would be a great way for someone to get involved with GHC development, because for the most part it's not deep technology, and there are lots of small improvements to make. A good way to start would be to create some feature-request tickets describing some improvements that could be made. Cheers, Simon