On Mon, Aug 29, 2011 at 6:21 AM, Bas van Dijk 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 opti
On 30 August 2011 01:16, Evan Laforge wrote:
> Interesting, maybe I misremembered? Or maybe there was some other guy
> who was trying to parallelize?
>
> Just out of curiosity, what benefit does a thread-safe ghc provide? I
> know ghc api users have go to some bother to not call re-entrantly...
On Mon, Aug 29, 2011 at 1:50 PM, Max Bolingbroke
wrote:
> On 27 August 2011 09:00, Evan Laforge 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 seem
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 b
On 27 August 2011 09:00, Evan Laforge 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 f
For package P,
"ghc-pkg unregister --user P" drops the global package if P is not in user.
"ghc-pkg unregister --global P" drops the user package if P is in user.
"ghc-pkg unregister --package-conf= P" drops the user or the global
package, preferring the user one, if P is not found in .
Same
Dear Ben,
Ben Gamari wrote:
> After looking into this issue in a bit more depth, I'm even more
> confused. In fact, I would not be surprised if I have stumbled into a
> bug in the GC.
[...]
> MessagesMessage
> |
> | msmpp
> \/
> QueryMe
Hi,
First of all, I love the idea of default superclass instances!
About the opt-out feature, the problem with option 3 is only present
if the superclass instance is defined in another module (you won't see
unexpected behavior from your own instances). One solution is to use
option 3 if the offen
> In any case, maybe Simon Hengel can try using this.
I just tried Data.Generics.GPS with the simple example from my previous
post, and it did not hit any error thunks.
I may try to do something more useful with it, and let you know how that
worked out.
Cheers,
Simon
___
On 29 August 2011 11:11, Aleksey Khudyakov wrote:
>> "Option 3 avoids that problem but risks perplexity: if I make use of
>> some cool package which introduces some Foo :: * -> *, I might notice
>> that Foo is a monad and add a Monad Foo instance in my own code,
>> expecting the Applicative Foo in
> "Option 3 avoids that problem but risks perplexity: if I make use of
> some cool package which introduces some Foo :: * -> *, 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 fi
11 matches
Mail list logo
