On Sat, 2012-02-25 at 11:38 +0100, José Pedro Magalhães wrote:
> 2012/2/25 Andres Löh
> > 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
2012/2/25 Andres Löh
> > 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 "
> 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é
> expl
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 ass
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 n
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:
[...]
Hi Andres,
2012/2/24 Andres Löh
> 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 cer
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
_
On Fri, 2012-02-24 at 09:32 +0100, Jos Pedro Magalhes wrote:
>
>
> 2012/2/24 Maxime Henrion
> On Fri, 2012-02-24 at 07:49 +0100, Jos Pedro Magalhes wrote:
> > Hi,
> >
> > 2012/2/23 Maxime Henrion
> >
> > > * Why do you have the instance:
>
2012/2/24 Maxime Henrion
> On Fri, 2012-02-24 at 07:49 +0100, Jos Pedro Magalhes wrote:
> > Hi,
> >
> > 2012/2/23 Maxime Henrion
> >
> > > * Why do you have the instance:
> > >
> > > instance GDeepSeq V1 where grnf _ = ()
> > >
> > > The only way to constr
On Fri, 2012-02-24 at 07:49 +0100, Jos Pedro Magalhes wrote:
> Hi,
>
> 2012/2/23 Maxime Henrion
>
> > * Why do you have the instance:
> >
> > instance GDeepSeq V1 where grnf _ = ()
> >
> > The only way to construct values of a void type is using ⊥.
Hi,
2012/2/23 Maxime Henrion
>
> > * 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.
>
> T
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
On Thu, 2012-02-23 at 23:24 +0100, Bas van Dijk wrote:
> On 23 February 2012 22:09, Maxime Henrion wrote:
> > On Sun, 2012-02-19 at 21:06 +0100, Bas van Dijk wrote:
> >> On 19 February 2012 18:11, Maxime Henrion wrote:
> >> > I'm guilty of not having preserved the "rnf :: a -> ()"
> >> > function
On 23 February 2012 22:09, Maxime Henrion wrote:
> On Sun, 2012-02-19 at 21:06 +0100, Bas van Dijk wrote:
>> On 19 February 2012 18:11, Maxime Henrion wrote:
>> > I'm guilty of not having preserved the "rnf :: a -> ()"
>> > function as the class function though, it's a wrapper around "deepseq"
>>
2012/2/23 Maxime Henrion :
> 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", because I've obs
Bas van Dijk 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.
btw, how much is GH
2012/2/20 José Pedro Magalhães :
>>
>>
>> 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
Hi,
2012/2/19 Bas van Dijk
>
> 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 already using the d
On Sun, 2012-02-19 at 21:06 +0100, Bas van Dijk wrote:
> On 19 February 2012 18:11, Maxime Henrion 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
On 19 February 2012 18:11, Maxime Henrion 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 as the generic
On Sun, 2012-02-19 at 16:17 +0100, Bas van Dijk wrote:
> On 19 February 2012 13:12, Maxime Henrion 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,
On 19 February 2012 13:12, Maxime Henrion 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 NFData a where
rn
23 matches
Mail list logo
