I was looking into Hana and I was surprised to see that it has a concept of a type (a "container of types" of sort, something like a one-element tuple with no actual value), but types (a sequence of type) is an experimental feature.
Does anyone know why? What is complicated about a list of types as opposed to a container of a single type?
The answer is basically what Jason said:
I'd like to see types as a
hana::Sequencebut it wouldn't pass the laws as it won't hold any kind of value (like values with run-time state).
The "problem" is that a hana::types could not be made a hana::Sequence, because a hana::Sequence is supposed to be able to hold arbitrary things, not only types. While this may not seem like a big deal, it actually is. For example, we would also not be able to satisfy hana::Monad, since that requires hana::flatten, whose signature is M<M<T>> -> M<T> for an arbitrary hana::Monad M. Since hana::types can only hold types, you could not have e.g. hana::types<hana::types<int, char>, hana::types<float, long>> without special-casing the whole thing.
Whatever the solution is, I'd like to find a solution that does not break the conceptual integrity of Hana, while still allowing for a more compile-time efficient type list.