"Data.TupleFields" for review

[Isaac Dupree]

Henning Thielemann wrote:
>   Translated to the tuple issue, I use only one function of type
>     field1 :: f -> t -> (f,t)
>   which is a combination of 'get' and 'set'.
>   Using this function you can implement a generic 'set', 'get', and
> 'update'. Of course, you can argue that it is bad style to put the
> distinct 'set' and 'get' functionalities into one function.

I like that style. It reminds me of the zipper pattern, of accessors (or 
something like that).  ...which is more important for more complicated 
things (Maps?) (Uniplate.)

I don't know when I'd want to use a function polymorphic in tuple size - 
_personally_ I'd rather stick to simpler types and ... probably 
pattern-matching.  It's too bad selectors via pattern-matching take a 
bit more syntax than (,,this,) unless you're already in a pattern-match 
location... ( (_,_,this,_) ).  Large tuples whose size can change might 
be better represented with record syntax.  So I'm not the target 
audience of this library :)

Isaac