Would you have an example of a type for which it would be useful to have
a DeepSeq instance, and that would require a V1 instance? I cannot think
of one now; I originaly thought it would be necessary to permit deriving
DeepSeq instances for types tagged with void types, but as José
explained,
2012/2/25 Andres Löh andres.l...@googlemail.com
Would you have an example of a type for which it would be useful to have
a DeepSeq instance, and that would require a V1 instance? I cannot think
of one now; I originaly thought it would be necessary to permit deriving
DeepSeq instances for
On Sat, 2012-02-25 at 11:38 +0100, José Pedro Magalhães wrote:
2012/2/25 Andres Löh andres.l...@googlemail.com
Would you have an example of a type for which it would be
useful to have
a DeepSeq instance, and that would require a V1 instance? I
cannot think
On Fri, 2012-02-24 at 07:49 +0100, Jos Pedro Magalhes wrote:
Hi,
2012/2/23 Maxime Henrion mhenr...@gmail.com
* Why do you have the instance:
instance GDeepSeq V1 where grnf _ = ()
The only way to construct values of a void type is
2012/2/24 Maxime Henrion mhenr...@gmail.com
On Fri, 2012-02-24 at 07:49 +0100, Jos Pedro Magalhes wrote:
Hi,
2012/2/23 Maxime Henrion mhenr...@gmail.com
* Why do you have the instance:
instance GDeepSeq V1 where grnf _ = ()
The only
On Fri, 2012-02-24 at 09:32 +0100, Jos Pedro Magalhes wrote:
2012/2/24 Maxime Henrion mhenr...@gmail.com
On Fri, 2012-02-24 at 07:49 +0100, Jos Pedro Magalhes wrote:
Hi,
2012/2/23 Maxime Henrion mhenr...@gmail.com
* Why do
I don't understand what's going on here. Instances for V1 should of
course be defined if they can be! And in this case, a V1 instance
makes sense and should be defined. The definition itself doesn't
matter, as it'll never be executed.
Cheers,
Andres
Hi Andres,
2012/2/24 Andres Löh andres.l...@googlemail.com
I don't understand what's going on here. Instances for V1 should of
course be defined if they can be! And in this case, a V1 instance
makes sense and should be defined. The definition itself doesn't
matter, as it'll never be
Hi.
I don't understand what's going on here. Instances for V1 should of
course be defined if they can be! And in this case, a V1 instance
makes sense and should be defined. The definition itself doesn't
matter, as it'll never be executed.
The definition certainly matters:
[...]
You're
On Fri, 2012-02-24 at 15:28 +0100, Andres Löh wrote:
Hi.
I don't understand what's going on here. Instances for V1 should of
course be defined if they can be! And in this case, a V1 instance
makes sense and should be defined. The definition itself doesn't
matter, as it'll never be
On Thu, 2012-02-23 at 23:24 +0100, Bas van Dijk wrote:
Some nitpicking:
* In the instance:
instance GDeepSeq U1 where grnf _ = ()
I think it makes sense to pattern match on the U1 constructor, as in:
grnf U1 = ().
I haven't checked if that's necessary but my fear is that assuming:
2012/2/23 Maxime Henrion mhenr...@gmail.com:
According to criterion, the performance of the old generic-deepseq code
was 6 to 7 times worse than that of the deepseq package. After switching
the class function to rnf, it got on par, if not better than the deepseq
package. I'm saying if not,
On 23 February 2012 22:09, Maxime Henrion mhenr...@gmail.com wrote:
On Sun, 2012-02-19 at 21:06 +0100, Bas van Dijk wrote:
On 19 February 2012 18:11, Maxime Henrion mhenr...@gmail.com wrote:
I'm guilty of not having preserved the rnf :: a - ()
function as the class function though, it's a
On Thu, 2012-02-23 at 23:24 +0100, Bas van Dijk wrote:
On 23 February 2012 22:09, Maxime Henrion mhenr...@gmail.com wrote:
On Sun, 2012-02-19 at 21:06 +0100, Bas van Dijk wrote:
On 19 February 2012 18:11, Maxime Henrion mhenr...@gmail.com wrote:
I'm guilty of not having preserved the rnf
On Thu, 2012-02-23 at 23:45 +0100, Maxime Henrion wrote:
On Thu, 2012-02-23 at 23:24 +0100, Bas van Dijk wrote:
* Why do you have the instance:
instance GDeepSeq V1 where grnf _ = ()
The only way to construct values of a void type is using ⊥. And I
would expect that rnf ⊥ = ⊥, not
Hi,
2012/2/23 Maxime Henrion mhenr...@gmail.com
* Why do you have the instance:
instance GDeepSeq V1 where grnf _ = ()
The only way to construct values of a void type is using ⊥. And I
would expect that rnf ⊥ = ⊥, not (). I think the best thing is to just
remove the V1 instance.
2012/2/20 José Pedro Magalhães j...@cs.uu.nl:
One last issue: Say I have a type like: data T = C !Int
Currently GHC Generics can't express the strictness annotation. This
means that your deepseq will unnecessarily evaluate the Int (since it
will always be evaluated already). It would be nice
Bas van Dijk v.dijk@gmail.com writes:
Also in my experience (with generics support in aeson and cereal) it's
a very good idea (performance-wise) to INLINE your methods like I did
in my previous message. Of course the only way to know for sure is the
create some (criterion) benchmarks.
Hello all,
Yesterday I uploaded a new package on Hackage called generic-deepseq. It
implements the 'deepseq' function generically using the new GHC.Generics
framework as found in GHC = 7.2. It can be used as a replacement for
the deepseq package.
Given that hackage is currently down, here is an
On 19 February 2012 13:12, Maxime Henrion mhenr...@gmail.com wrote:
Any suggestions are welcome.
Nice work but it would be nice to have this functionality directly in
the deepseq package as in:
#ifdef GENERICS
{-# LANGUAGE DefaultSignatures, TypeOperators, FlexibleContexts #-}
#endif
class
On Sun, 2012-02-19 at 16:17 +0100, Bas van Dijk wrote:
On 19 February 2012 13:12, Maxime Henrion mhenr...@gmail.com wrote:
Any suggestions are welcome.
Nice work but it would be nice to have this functionality directly in
the deepseq package as in:
#ifdef GENERICS
{-# LANGUAGE
On 19 February 2012 18:11, Maxime Henrion mhenr...@gmail.com wrote:
If you're not dealing with an abstract datatype, you _shouldn't_ have an
explicit instance, because it would be possible to write an incorrect one,
while that is impossible if you just derive a generic implementation
(as long
On Sun, 2012-02-19 at 21:06 +0100, Bas van Dijk wrote:
On 19 February 2012 18:11, Maxime Henrion mhenr...@gmail.com wrote:
If you're not dealing with an abstract datatype, you _shouldn't_ have an
explicit instance, because it would be possible to write an incorrect one,
while that is
Hi,
2012/2/19 Bas van Dijk v.dijk@gmail.com
I do think it's better to integrate this into the deepseq package (and
thus removing the default implementation of rnf). Otherwise we end up
with two ways of evaluating values to normal form.
I agree with this, and I guess many people are
24 matches
Mail list logo
