RE: Superclass defaults
| Won't option 1 Reject this as a duplicate instance declaration, which | indeed it is. conflict with design goal 1: a class C can be | re-factored into a class C with a superclass S, without disturbing any | clients? Yes, option 1 does conflict with design goal 1; good point. There seems to be a lot of support for Option 3... but what about Option 2 (ie pre-empt but give a warning)? I've updated the wiki page http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances to reflect this discussion. Simon | -Original Message- | From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users- | boun...@haskell.org] On Behalf Of Sebastian Fischer | Sent: 30 August 2011 03:49 | To: Bas van Dijk | Cc: glasgow-haskell-users@haskell.org; Simon Peyton-Jones | Subject: Re: Superclass defaults | | On Mon, Aug 29, 2011 at 6:21 AM, Bas van Dijk v.dijk@gmail.com wrote: | | Won't option 1 Reject this as a duplicate instance declaration, which | indeed it is. conflict with design goal 1: a class C can be | re-factored into a class C with a superclass S, without disturbing any | clients? | | If yes, I prefer option 3: | | Allow the explicit to supersede the intrinsic default silently. | | The argument against this option is: | | I might notice | that Foo is a monad and add a Monad Foo instance in my own code, | expecting the Applicative Foo instance to be generated in concert; to | my horror, I find my code has subtle bugs because the package | introduced a different, non-monadic, Applicative Foo instance which | I'm accidentally using instead. | | This seems rare enough that it's feasible to issue a warning if a | default instance is overwritten by an explicit instance in a different | module which would prevent the described perplexity. This wouldn't, | for example, disturb the transformers example mentioned by Bas because | (I think) all instances are defined in the same module. | | Sebastian | | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to synchronously shutdown the event manager loop
On 31 August 2011 01:11, Bas van Dijk v.dijk@gmail.com wrote: So it seems like a bug in GHC. I will create a ticket in the morning. Ticket created: http://hackage.haskell.org/trac/ghc/ticket/5443 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Superclass defaults
| There seems to be a lot of support for Option 3... but what about Option 2 (ie pre-empt but give a warning)? I think option 2 sounds very good. Possibly with the exception of only warning when the manual instance is in another module, since you will never experience the perplexity described in option 3 if you have written the instance yourself. This means that most modules will not get any warning when a class is changed to give a default superclass instance. Even omitting the warning only when the instantiated datatype is in the same module as the instances might be enough to suppress most warnings. Also i wonder if there will be a way of suppressing the warnings and still have compatible code (with the current compiler, preferably without using CPP)? /J On 31 August 2011 09:21, Simon Peyton-Jones simo...@microsoft.com wrote: | Won't option 1 Reject this as a duplicate instance declaration, which | indeed it is. conflict with design goal 1: a class C can be | re-factored into a class C with a superclass S, without disturbing any | clients? Yes, option 1 does conflict with design goal 1; good point. There seems to be a lot of support for Option 3... but what about Option 2 (ie pre-empt but give a warning)? I've updated the wiki page http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances to reflect this discussion. Simon | -Original Message- | From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users- | boun...@haskell.org] On Behalf Of Sebastian Fischer | Sent: 30 August 2011 03:49 | To: Bas van Dijk | Cc: glasgow-haskell-users@haskell.org; Simon Peyton-Jones | Subject: Re: Superclass defaults | | On Mon, Aug 29, 2011 at 6:21 AM, Bas van Dijk v.dijk@gmail.com wrote: | | Won't option 1 Reject this as a duplicate instance declaration, which | indeed it is. conflict with design goal 1: a class C can be | re-factored into a class C with a superclass S, without disturbing any | clients? | | If yes, I prefer option 3: | | Allow the explicit to supersede the intrinsic default silently. | | The argument against this option is: | | I might notice | that Foo is a monad and add a Monad Foo instance in my own code, | expecting the Applicative Foo instance to be generated in concert; to | my horror, I find my code has subtle bugs because the package | introduced a different, non-monadic, Applicative Foo instance which | I'm accidentally using instead. | | This seems rare enough that it's feasible to issue a warning if a | default instance is overwritten by an explicit instance in a different | module which would prevent the described perplexity. This wouldn't, | for example, disturb the transformers example mentioned by Bas because | (I think) all instances are defined in the same module. | | Sebastian | | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Superclass defaults
Hi Sorry to be late again...I'm trying to have what's laughably described as a holiday, but it seems more like the common cold to me. On 31 Aug 2011, at 08:52, Jonas Almström Duregård wrote: | There seems to be a lot of support for Option 3... but what about Option 2 (ie pre-empt but give a warning)? At least in the short term, I think Option 2 is a good compromise. It's true that when I started using default superclass instances (which SHE supports) in the Epigram codebase, the first thing I had to do was delete a bunch of dull default instance stacks. That was fun, but it wasn't nothing. I think option 2 sounds very good. Possibly with the exception of only warning when the manual instance is in another module, since you will never experience the perplexity described in option 3 if you have written the instance yourself. I become perplexed very easily. I think we should warn whenever silent pre-emption (rather than explicit) hiding is used to suppress a default instance, because it is bad --- it makes the meaning of an instance declaration rather more context dependent. Perhaps a design principle should be that to understand an instance declaration, you need only know (in addition) the tower of class declaration s above it: it is subtle and worrying to make the meaning of one instance declaration depend on the presence or absence of others. Arguably, option 1 does not conflict with design goal 1. Design goal 1 supports a methodology for refining a class into a hierarchy without creating the need for stacks of default instances or breaking code. If the new superclass is a brand new thing without legacy instances, there's no problem. If we'd had this mechanism in place, Functor would always have been made a superclass of Monad, Applicative would have been easily inserted, and we wouldn't have the stacks of manually added default instances to worry about. The main problem with Option 1 is in dealing with the legacy of classes which currently require a stack of default instances, creating a hierarchy from parts which already exist. Option 1 would create a bunch of instance conflicts and thus demand changes to code. Design goal 1 isn't very explicit (sorry!) about this distinction between introducing new classes as superclasses and building hierarchies from legacy classes, but it was the former I intended. I always expected the latter to cause trouble. If it is also a design goal to minimize damage with respect to the current unfortunate situation, then Option 1 is problematic. Whatever we might wish, we are where we are. We should be pragmatic. I think we should set Option 1 as the direction of travel, but go with Option 2 for the moment. We should make sure that the warnings generated by Option 2 are sufficiently informative that it is easy to track down the conflicts and resolve them explicitly, for Option 1 compliance. Does this sound plausible? Conor ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Parallel --make (GHC build times on newer MacBook Pros?)
On 30/08/2011 00:42, Thomas Schilling wrote: The performance problem was due to the use of unsafePerformIO or other thunk-locking functions. The problem was that such functions can cause severe performance problems when using a deep stack. The problem is that these functions need to traverse the stack to atomically claim thunks that might be under evaluation by multiple threads. The latest version of GHC should no longer have this problem (or not as severely) because the stack is now split into chunks (see [1] for performance tuning options) only one of which needs to be scanned. So, it might be worth a try to re-apply that thread-safety patch. [1]: https://plus.google.com/107890464054636586545/posts/LqgXK77FgfV I think I would do it differently. Rather than using unsafePerformIO, use unsafeDupablePerformIO with an atomic idempotent operation. Looking up or adding an entry to the FastString table can be done using an atomicModifyIORef, so this should be fine. The other place you have to look carefully at is the NameCache; again an atomicModifyIORef should do the trick there. In GHC 7.2.1 we also have a casMutVar# primitive which can be used to build lower-level atomic operations, so that might come in handy too. Cheers, Simon On 29 August 2011 21:50, Max Bolingbrokebatterseapo...@hotmail.com wrote: On 27 August 2011 09:00, Evan Laforgeqdun...@gmail.com wrote: Right, that's probably the one I mentioned. And I think he was trying to parallelize ghc internally, so even compiling one file could parallelize. That would be cool and all, but seems like a lot of work compared to just parallelizing at the file level, as make would do. It was Thomas Schilling, and he wasn't trying to parallelise the compilation of a single file. He was just trying to make access to the various bits of shared state GHC uses thread safe. This mostly worked but caused an unacceptable performance penalty to single-threaded compilation. Max ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Superclass defaults
On Wed, Aug 31, 2011 at 4:21 PM, Simon Peyton-Jones simo...@microsoft.com wrote: There seems to be a lot of support for Option 3... but what about Option 2 (ie pre-empt but give a warning)? I notice that the idea to only issue a warning if the explicit and implicit instances are in different modules was already halfway towards reaching option 2. I think it is fine to issue warnings also if both instances are in the same module. For newly written code, an explicit hiding clause removes context dependence (as Conor points out) so the warning is justified. For existing code where it generates too much noise the warning could be switched of selectively until the code gets cleaned up. Sebastian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 7.2.1
On 19 August 2011 17:15, Jens Petersen j...@community.haskell.org wrote: I have done a test build of 7.2.1 for Fedora [17]: http://koji.fedoraproject.org/koji/taskinfo?taskID=3267317 Since the test rpms are now gone from Koji and I don't think I will start building 7.2 properly for Fedora until after ICFP I have placed those rpms here for now: http://petersen.fedorapeople.org/ghc-7.2/ if anyone is looking for them. They should work fine with F15 and F16 (untested but probably with F14 too). (I forgot to archive the original src rpm for the build but I believe the one I uploaded is essentially equivalent.) Just note that the bootstrap test rpms don't have ABI hash metadata. I haven't committed the packaging yet to fedora git either, if there is interest I am happy to push it to a branch there. Jens ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
