up vote 29 down vote favorite
3

The HList package was based on what is by now ancient Haskell technology. The simple question is: given all the wonderful new features of the last 8 years' worth of Haskell/GHC development, would a "modern" HList be built very differently? I realize that the answer here might well be no, that for the particular case of HList, the technology used then still produces the most elegant solution.

I have read many of the items documented on the extensible records page, the only real competitor (i.e. one which is implemented as a library available on hackage) is the records package. Or are there missing links from extensible records?

share
up vote 10 down vote accepted

The question for any of these packages is the scope of its goals. HList is actually 5 different implementations of labels, two of type equality, two of type casting, two of Record/RecordP, and the Variant vs TIC choice. All all similar but are different trade-offs of ease of use, portability, and extensions used.

The newer GHC features (GADTs, associated types, constraint kinds, polymorphic kinds, singleton types) may allow slightly different trade offs. In particular the singleton types may allow better labels, and polymorphic kinds may allow a more elegant Typeable/Data/Generics .

The "records" package you link to depends on the "kinds" package that claims:

"Haskell has no support for subkinds and subkind polymorphism. However, this package can be used to emulate subkinds of kind * and subkind variables."

But this is no longer true thanks to promotion of data type to kinds in new GHC versions. So this January 2012 package may be kind-of obsolete now.

As for records, perhaps a new system will draw from the latest round of polymorphic lenses: lens and/or lens-family.

share
2  
I was discussing the relation between lenses and extensible records with Russell (O'Connor) just this morning -- and it is not clear. Lenses are great for abstracting get/set of a single field in an aggregate, but less good at representing the aggregate itself. In any case, it seems like I should stick with HList (for now), and then try to find which of the zillions of variant I should choose to deal with the problem at hand (which is translating some O'Caml code which uses polymorphic variants AND row types AND Functors into Haskell). – Jacques Carette Aug 22 '12 at 21:02
2  
I did recently makes a HList-inspired thing: given a type-indexed-coproduct (TIP) thing and {handler for one of the cases} it returns either {the result of the handler} or {the TIP with a smaller type}. Chaining handlers together with >=> reduced the TIP case by case. I thought at the time it sort-of simulated pattern matching polymorphic variants. – Chris Kuklewicz Aug 22 '12 at 21:17

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.