[Hs-Generics] pervasiveness of Rec in TH-derived instant-generics representation types

[Nicolas Frisby]

Thanks for the quick response!

The Mappable class from Section 4.2 of the Fast and Easy! paper left
me with the feeling that Rec and Var were useful. Has something else
replaced that use in those examples or am I overestimating their
usefulness?

Would there be any harm in determining the mutually recursive
datatypes and Rec-tagging exactly those fields that are part of the
mutually recursive group? We might have some bitrotted TH code lying
around that identifies the strongly connected types in a mutual
recursive group of declarations. Please let me know if that's an
attractive way forward for determining whether or not to insert the
Rec.

2011/2/16 José Pedro Magalhães <jpm at cs.uu.nl>:
> Hi,
>
> On Wed, Feb 16, 2011 at 23:03, Nicolas Frisby <nicolas.frisby at gmail.com>
> wrote:
>>
>> In instant-generics-0.2.1, the TH functions for deriving the Rep type
>> instances insert the "Rec" type at every field. Is there a consequence
>> to this?
>>
>> This behavior seems at odds with the paper; isn't Rec only meant as an
>> indicator of recursive occurrences within the original data type?
>
> I think that is the current behavior, yes. I've given some thought to this
> in the generic deriving paper [1]; in fact, tagging a recursive occurrence
> with Var or Rec doesn't make much difference, since in the end it is just a
> tag. You can't, for instance, define an fmap function by mapping over the
> things tagged with Var, because you know nothing about the types of those
> things.
>
> This doesn't mean they are entirely useless, though. In fact,
> instant-generics makes use of this in the empty function [2]: on a sum, it
> looks ahead to see if there are Rec's on the left or right, and proceeds to
> the side that has no Rec's. This guarantees that a finite element will be
> generated (if there is one). So, tagging only the occurrences of the
> original type with Rec wouldn't be very helpful, since datatypes can be
> mutually recursive.
>
> I think the best approach is to tag everything as Rec, except for parameters
> and base types. That is what we do in UHC [1], if I recall correctly.
>
> And, as the comment says, the TH code for instant-generics should be updated
> to generate Var tags too. I haven't gotten around to do that yet, but if
> it's important for you I can have a look. Of course, patches are welcome too
> [3].
>
>
> Cheers,
> Pedro
>
> [1] http://www.dreixel.net/research/pdf/gdmh.pdf
> [2]
> http://hackage.haskell.org/packages/archive/instant-generics/0.2.1/doc/html/Generics-Instant-Functions-Empty.html
> [3] https://subversion.cs.uu.nl/repos/project.dgp-haskell.libraries/Instant/
>
>>
>> Thanks.
>>
>> ---
>>
>> snippet from http://j.mp/gK8MOk ; repField is invoked for every field
>> of every constructor by all of the relevant TH entry-points.
>>
>>  repField :: (Name, [Name]) -> Type -> Q Type
>>  --repField d t | t == dataDeclToType d = conT ''I
>>  repField d t = conT ''Rec `appT` return t
>>
>>  repField' :: (Name, [Name]) -> Name -> (Name, Strict, Type) -> Q Type
>>  --repField' d ns (_, _, t) | t == dataDeclToType d = conT ''I
>>  repField' (dt, vs) ns (f, _, t) = conT ''Rec `appT` return t
>>  -- Note: we should generate Var too, at some point
>>
>> _______________________________________________
>> Generics mailing list
>> Generics at haskell.org
>> http://www.haskell.org/mailman/listinfo/generics
>
>