[Hs-Generics] Request for code review: Generics for tuple/newtype introspection

[AntC]

> José Pedro Magalhães <jpm <at> cs.uu.nl> writes:

Thanks Pedro,

> > On Fri, Dec 13, 2013 at 12:04 AM, Anthony Clayden wrote:
> >
> > Questions:
> > * These pile-ups of types (M1 D ... (M1 C ... (...))) seem
> >    hairy.
> >   Is that the best way to control the depth of recursion?
> >
> 
> ... The advantage of the "hairy types" you have right now
> is that these would be (obscure) compile-time errors.
> 

OK. For this functionality, I prefer compile-time fail to run-time.

> >
> > * The explicit data constructors in the pattern matching
> >   are a bit temperamental w.r.t. undefined values. ...
>

> I don't see why you need |undefined| at all. Unless you are
> calling |tupToAttribs| with |undefined|; is that the case? 

Yes: a relation (aka database table) could be empty, in which case I have 
only the type of its tuple, no value.
(And actually, for a bit of background, this was the main point of the 
exercise: I am in debate on another forum about whether a relation needs 
a "heading" -- whose main purpose seems to be to deliver the attributes 
and their based-on types even when the relation (body) is empty. (The 
counter-argument is along the lines: how can a non-existent value have a 
type?) I'm claiming that you don't need a "heading", because you can reify 
the schema from the tuple type -- even if you don't have a tuple. And I 
now have a function to prove it, thank you Generics!)

Cheers
AntC