Re: Parallel --make (GHC build times on newer MacBook Pros?)

2011-09-02 Thread Simon Marlow
On 01/09/2011 18:02, Evan Laforge wrote: It's an interesting idea that I hadn't thought of. There would have to be an atomic file system operation to commit a compiled module - getting that right could be a bit tricky (compilation isn't deterministic, so the commit has to be atomic). I

Re: Parallel --make (GHC build times on newer MacBook Pros?)

2011-09-02 Thread Joachim Breitner
Hi, Am Freitag, den 02.09.2011, 09:07 +0100 schrieb Simon Marlow: On 01/09/2011 18:02, Evan Laforge wrote: It's an interesting idea that I hadn't thought of. There would have to be an atomic file system operation to commit a compiled module - getting that right could be a bit tricky

Re: Superclass defaults

2011-09-02 Thread Jonas Almström Duregård
Hi, On 31 August 2011 12:22, Conor McBride co...@strictlypositive.org wrote: 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

Re: Superclass defaults

2011-09-02 Thread Conor McBride
Hi On 2 Sep 2011, at 10:55, Jonas Almström Duregård wrote: On 31 August 2011 12:22, Conor McBride co...@strictlypositive.org wrote: 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,

Re: Superclass defaults

2011-09-02 Thread Brandon Allbery
I hope I am misunderstanding this 2011/9/2 Conor McBride co...@strictlypositive.org Also, if I understand you correctly, you say the current situation is exceptional, and suggest option 2 as a temporary solution to it. You seem convinced that these kind of situations will not appear in

Re: Superclass defaults

2011-09-02 Thread Jonas Almström Duregård
The question then comes down to whether that warning should ever be strengthened to an error. Indeed. I agree that such a scenario is possible. The present situation gives no choice but to do things badly, but things often get done badly the first time around anyway. Perhaps I'm just

Re: Superclass defaults

2011-09-02 Thread Conor McBride
Hi On 2 Sep 2011, at 16:34, Brandon Allbery wrote: I hope I am misunderstanding this I wrote: I agree that such a scenario is possible. The present situation gives no choice but to do things badly, but things often get done badly the first time around anyway. Perhaps I'm just grumpy,

Re: Superclass defaults

2011-09-02 Thread Conor McBride
On 2 Sep 2011, at 18:19, Jonas Almström Duregård wrote: I agree. Option 2 FTW :) The recent discussion concerns whether option 2 should eventually be shifted to option 1. Everyone seems to agree that option 2 should be used initially. A similar warning should perhaps indicate that a hiding

RE: Superclass defaults

2011-09-02 Thread Simon Peyton-Jones
Too many words! I'm losing track. What I'm proposing is Option 2 under The design of the opt-out mechanism on http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances I believe that meets everyone's goals: * A warning encourages you to fix the client code * But you can turn it

Re: Superclass defaults

2011-09-02 Thread Jonas Almström Duregård
I agree. Option 2 FTW :) The recent discussion concerns whether option 2 should eventually be shifted to option 1. Everyone seems to agree that option 2 should be used initially. Regards, Jonas On 2 September 2011 18:55, Simon Peyton-Jones simo...@microsoft.com wrote: Too many words!  I'm