[Haskell-cafe] tuple and HList

[Frederik Eaton]

> > This was brought up in passing in a recent conversation on
> > haskell-cafe

Sorry, mairix was malfunctioning...

> > It certainly seems like an interesting idea, Would type inference
> > still work okay?

I don't understand all of the issues. One is that in the HList paper,
rather than constructing HLists with data constructors, they use
special functions which guarantee through class constraints that the
tail of an HList is a valid HList, and not some other random type.
(There was some reason that they didn't want to put the constraints on
the data type itself.) But this prevents us from using the same syntax
in construction and pattern matching. And if tuples were syntactic
sugar for something that constructs a valid HList then it seems the
constraints wouldn't be necessary.

> > The other problem mentioned is that they are not quite isomorphic,
> > since HLists are equivalant to (a,(b,c)) rather than (a,b,c), but
> > changing HCons so that it is strict in its second argument makes them
> > behave the same I think..

And it's important to be able to costruct a HList with one element.
Perhaps the syntax (a,) could be used for a tuple with one element?

> Since most of the HList functionality is defined using type classes, we
> could probably declare a new type, TCons, make it strict in the second
> argument, and use it alongside HCons.
> 
>     data TCons a b = TCons a !b
> 
> One way t make tuples into sugar for HLists would be to effectively have
> a series of declarations like these:
> 
>     type (a,b)   = TCons a (TCons b HNil)
>     type (a,b,c) = TCons a (TCons b (TCons c HNil))
> 
> But then we can't use tuples in instance declarations. That is, there
> isn't any way to desugar 'instance Functor ((,) a)' without using a type
> lambda.

I'm not sure I understand this, but the intent was that you'd use e.g.
TCons instead of the tuple syntax in instance declarations.

> On the other hand, using HLists for tuples means we can have projection
> functions that work on any tuple arity, which would be nice.

Another thing which I don't think is mentioned in the paper, which is
convenient, is that you can define HLists all of whose elements are
members of a given class:

class HListShow l
instance HListShow HNil
instance (Show a, HListShow l) => HListShow (a :* l)

It's not as clean as if you could parameterize over classes, but it's
better than this...

(Show a, Show b) => Show (a, b)
(Show a, Show b, Show c) => Show (a, b, c)
(Show a, Show b, Show c, Show d) => Show (a, b, c, d)
(Show a, Show b, Show c, Show d, Show e) => Show (a, b, c, d, e)

Frederik

-- 
http://ofb.net/~frederik/