RE: Massive slowdown in mwc-random after switching to use of primitive package

2010-07-13 Thread Simon Peyton-Jones
| The head has -dsuppress-coercions which omits coercion terms when pretty | printing Core. It would be easy to backport that to 6.12. The HEAD also has a coercion optimiser that dramatically shrinks some large coercion terms. | I might revert both mwc-random and statistics back to using plain

Re: mallocForeignPtr vs. C

2010-07-13 Thread Simon Marlow
On 13/07/2010 05:49, Evan Laforge wrote: On Mon, Jul 12, 2010 at 6:54 PM, John Meachamj...@repetae.net wrote: Hi, is a StablePtr what you are after? Indeed, it looks like StablePtr will get me what I want. It's a little less convenient than FunPtr because I'm already doing some finalization

RE: Casting + eta reduction

2010-07-13 Thread Simon Peyton-Jones
It compiles to lift f d = f (d `cast` blah) which seems fine to me. Are you unhappy with that? Simon From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Louis Wasserman Sent: 09 July 2010 03:30 To: glasgow-haskell-users@haskell.org

Re: Casting + eta reduction

2010-07-13 Thread Louis Wasserman
Mmmm, let's give a slightly different example: foo :: Foo - Int foo (Foo a) = a + 1 bar :: Int - Int bar = foo . Foo and I'd expect bar to be replaced with (foo `cast` (Int - Int)) and inlined, eliminating an allocation. In general, we'd get the equivalent of the no-allocation versions of

Re: Casting + eta reduction

2010-07-13 Thread Louis Wasserman
Or a different way: I want -fdo-lambda-eta-expansion (which, if I understand correctly, actually triggers eta *reduction*) to eliminate argument casts, as well. My motivation: I'm working on a generalized trie library, and due to http://hackage.haskell.org/trac/ghc/ticket/4185, I can't use

Re: mallocForeignPtr vs. C

2010-07-13 Thread Axel Simon
Hi Evan, Ed, On Jul 12, 2010, at 22:53, Edward Z. Yang wrote: Excerpts from Evan Laforge's message of Mon Jul 12 16:43:45 -0400 2010: Yeah, that's definitely the safest and simplest. But the copying defeats the purpose of passing a pointer in the first place, which was to not have to

Re: mallocForeignPtr vs. C

2010-07-13 Thread Edward Z. Yang
Excerpts from Axel Simon's message of Tue Jul 13 16:03:01 -0400 2010: If your C code has a way to properly unref a pointer then you could wrap your ForeignPtr in a StablePtr and pass that to C land. Once C has freed the StablePtr the ForeignPtr can become dead when Haskell has dropped

Re: mallocForeignPtr vs. C

2010-07-13 Thread Axel Simon
On Jul 13, 2010, at 22:17, Edward Z. Yang wrote: Excerpts from Axel Simon's message of Tue Jul 13 16:03:01 -0400 2010: If your C code has a way to properly unref a pointer then you could wrap your ForeignPtr in a StablePtr and pass that to C land. Once C has freed the StablePtr the ForeignPtr

Re: mallocForeignPtr vs. C

2010-07-13 Thread Edward Z. Yang
Excerpts from Axel Simon's message of Tue Jul 13 16:28:29 -0400 2010: Well, if the C code hangs on to the StablePtr that wraps the ForeignPtr, its finalizer won't be run. But can run again once the StablePtr is freed. So you can take out the Ptr in the ForeignPtr and use it in C land as

GADT related bug in GHC type checker

2010-07-13 Thread George Giorgidze
Hi, I have encountered a bug in GHC type checker. I have stripped down my code to small manageable example that illustrates the bug: {-# LANGUAGE GADTs #-} {-# OPTIONS -Wall #-} module StrangeGADT where data Q a where ToQ :: (QA a) = a - Q a Sum :: (QA a, Num a) = Q [a] - Q a class QA a

Re: GADT related bug in GHC type checker

2010-07-13 Thread Daniel Fischer
On Wednesday 14 July 2010 00:11:00, George Giorgidze wrote: Hi, I have encountered a bug in GHC type checker. I have stripped down my code to small manageable example that illustrates the bug: {-# LANGUAGE GADTs #-} {-# OPTIONS -Wall #-} module StrangeGADT where data Q a where ToQ ::