"Modern" HList?

Question

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?

Answer 1

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.