...

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/

That's a neat technique. Since it's so general it would be nice if there were a way to make it more automatic, could one use template haskell? It seems one should be able to write HListConstraint $(mkConstraint Show) l to generate the declarations automatically. Frederik On Sun, Mar 20, 2005 at 11:05:06PM +0000, Keean Schupke wrote:

Frederik Eaton wrote:

...

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)

You can avoid the need to declare a new class for each constrained list by using the following:

...

class Constraint c a

data SHOW instance Show a => Constraint SHOW a

class HListConstraint c l instance HListConstraint c HNil instance (Constraint c a,HListConstraint c l) => HListConstraint c (HCons a l)

You can now constrain a list as follows:

...

assertShow :: HListConstraint SHOW l => l -> l assertShow = id

The type parameter can be made first class using:

...

showConstraint :: SHOW showConstraint = undefined

So we can now pass this as a parameter:

...

assertConstraintOnHList :: HListConstraint c l => c -> l -> l assertConstraintOnHList _ = id

Keean.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

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

Oleg has just pointed out that the 'Show' constraint bellow does not work if you try and use a function from the show class (say 'show'), as the function: test2 l = show l has the type: test2 :: forall a. (Show a) => a -> String The technique below works to constrain for membership of a class, So we know all elements in the list are instances of show, but we cannot call functions. The best thing here is to let the compiler infer any remaining constraints using: showList :: ConstrainedList SHOW l => l -> String showList = undefined test l | False = showList l | otherwise = show (hHead l) Here the 'False' guard is never executed, but its type is unified with the inferred type for 'show l'... ghci shows us: *Main> :type test test :: forall b a. (Show a, ConstrainedList SHOW (HCons a b)) => HCons a b -> String In other words use constraints only to enforce explicit requirements, the compiler can safely infer all required constraints from the code (IE just don't give signatures for the functions). Keean. Keean Schupke wrote:

You can avoid the need to declare a new class for each constrained list by using the following:

...

class Constraint c a

data SHOW instance Show a => Constraint SHOW a

class HListConstraint c l instance HListConstraint c HNil instance (Constraint c a,HListConstraint c l) => HListConstraint c (HCons a l)

You can now constrain a list as follows:

...

assertShow :: HListConstraint SHOW l => l -> l assertShow = id

The type parameter can be made first class using:

...

showConstraint :: SHOW showConstraint = undefined

So we can now pass this as a parameter:

...

assertConstraintOnHList :: HListConstraint c l => c -> l -> l assertConstraintOnHList _ = id

David Menendez wrote:

instance Functor ((,) a) where fmap f (x,y) = (x, f y)

If we get rid of '(,)' and redefine '(a,b)' as sugar for 'TCons a (TCons b HNil)' (or whatever), then there is no way to declare the above instance. I don't think that's a deal-killer, but it is a disadvantage.

You need to swap the arguments to TCons... data TCons l a = TCons !l a Then: instance Functor (TCons (TCons HNil a)) where fmap f (TCons (TCons HNil x) y) = TCons (TCons HNil (f x)) y) Keean.

Frederik Eaton writes:

...

You need to swap the arguments to TCons...

data TCons l a = TCons !l a

Then:

instance Functor (TCons (TCons HNil a)) where fmap f (TCons (TCons HNil x) y) = TCons (TCons HNil (f x)) y)

How does one solve this problem in general, i.e. when the arguments to a type are in the wrong order for an instance that one wants to declare?

In general? You either make a newtype or change the definition of the original type.

Someone on the haskell IRC channel mentioned that if you could derive instances for partially applied type synonyms then one could just make a dummy synonym with the arguments in the right order, but that doesn't appear to be premitted. The other question is why isn't it permitted.

As I understand it, the reason you can't do instances for partially applied type synonyms is because it makes instance selection ambiguous. For example: instance Functor ((,) a) where fmap f (x,y) = (x, f y) type RevPair a b = (b,a) instance Functor (RevPair a) where fmap f (x,y) = (f x, y) If I write 'fmap f (x,y)', do I get '(f x, y)' or '(x, f y)'? -- David Menendez http://www.eyrie.org/~zednenem/