On 09/02/2011 04:35, Kazu Yamamoto (山本和彦) wrote:
Hello Simon,
$ ghc-nightly2 ./kazu.hs -O2 -fforce-recomp; time ./kazu
[1 of 1] Compiling Main ( kazu.hs, kazu.o )
Linking kazu ...
4.17s real 4.16s user 0.01s system 99% ./kazu
OK. I ran it on 32bit Linux.
6.12.3 runghc
Hello,
My stats look very different.
6 RuleFired
1 ++
2 =#
1 foldr/app
1 unpack
1 unpack-list
Are your libraries compiled with -O2?
I don't know. How can I check?
I just installed ghc-7.0 by perl boot; configure; make; make install.
--Kazu
Friends
Just a heads-up. Pedro is working on implementing Generic Defaults, as
described in his Haskell Symposium 2010 paper
www.dreixel.net/research/pdf/gdmh_nocolor.pdf
It will replace (and improve on) the Derivable type classes stuff in GHC at
the moment, which was originally presented in
Hi,
2011/2/9 Simon Peyton-Jones simo...@microsoft.com
Friends
Just a heads-up. Pedro is working on implementing Generic Defaults, as
described in his Haskell Symposium 2010 paper
www.dreixel.net/research/pdf/gdmh_nocolor.pdf
It will replace (and improve on) the Derivable type classes
The Derivable type class extension is barely used, I believe, and isn't even
documented in the manual.
Isn't it this?:
http://www.haskell.org/ghc/docs/latest/html/users_guide/generic-classes.html
Oh yes, silly me. It is documented!
Simon
From: José Pedro Magalhães [mailto:j...@cs.uu.nl]
2011/2/9 Simon Peyton-Jones:
Friends
Just a heads-up. Pedro is working on implementing Generic Defaults, as
described in his Haskell Symposium 2010 paper
www.dreixel.net/research/pdf/gdmh_nocolor.pdf
It will replace (and improve on) the Derivable type classes stuff in GHC
at the moment,
Hello,
I want to use the RULES pragma and cannot get my rules to fire. Here is a
simplified example of what I'm trying.
I define my own version of foldMap for lists:
fold :: Monoid m = (a - m) - [a] - m
fold f = foldr mappend mempty . map f
-- alternative, trying to avoid
On Wednesday 09 February 2011 16:23:15, Sebastian Fischer wrote:
Why don't the rules fire, what can I change such that they do, and what
to get rid of the warning for the second rule (which I think is the one
I should use)?
Didn't spot that, sorry.
Best regards,
Sebastian
Here is the
In general it's quite hard to solve this problem without risking losing sharing.
However in this case I added a simple arity analyser after the 7.0.1 release
which solves the problem. It'll be in 7.0.2.
Try with HEAD and check it does what you expect.
Simon
| -Original Message-
|
On Wednesday 09 February 2011 16:23:15, Sebastian Fischer wrote:
Why don't the rules fire,
Because the 'match' is at the wrong type. In main, idGen appears as
idGen_anJ :: ([()] - [[()]]) - [[()]] - [[()]]
at some point (yay for ghc -v4), so it doesn't match g's polymorphic type.
what can I
In my one serious attempt to use git for one of my own projects, some
seemingly-innocuous operation deleted a file on me and I lost a couple
hours of work. I agree with the people who have said that git's
documentation and semantics are highly confusing, moreso than darcs's.
For example, what
I just noticed that the discussion has been concluded and I was replying to an
old thread. I apologize for the noise.
On Wed, Feb 9, 2011 at 6:56 PM, Dan Knapp dan...@gmail.com wrote:
In my one serious attempt to use git for one of my own projects, some
seemingly-innocuous operation deleted a
Why don't the rules fire,
Because the 'match' is at the wrong type.
This was the correct hint, thanks!
what can I change such that they do,
Type signatures.
Initially, I thought that just leaving out the polymorphic signature should
fix the problem. But I think it cannot be fixed by
Simon Peyton-Jones wrote:
Generic Defaults... will replace... the Derivable type classes
stuff... in GHC 7.2 or 7.4...
Please yell if you are a secret user of derivable type classes,
so this change would discombobulate you.
Could you give us a preview of the parts of the syntax
spectrum that
I've been using ghc-7.1.20110125 and it does indeed help a great deal.
I've tried compiling several problematic functions and in most cases
the problem is gone. However, in one of my test cases the closures are
still being constructed:
let {
lvl8_s1S8
::
15 matches
Mail list logo