I am really interested in finding out where the differences are, and more generally, to identify canonical use cases where HLists cannot be used (or rather, don&#39;t yield any benefits over regular lists).

(I am aware that there are 22 (I believe) ``TupleN`` in Scala, whereas one only needs a single HList, but that is not the kind of conceptual difference I am interested in.)

I&#39;ve marked a couple of questions in the text below. It might not actually be necessary to answer them, they are more meant to point out things that are unclear to me, and to guide the discussion in certain directions.

### Motivation

I&#39;ve recently seen a couple of answers on SO where people suggested to use HLists (for example, as provided by [Shapeless][1]), including a deleted answer to [this question][2]. It gave rise to [this discussion][3], which in turn sparked this question.

### Intro

It seems to me, that hlists are only useful when you know the number of elements and their precise types statically. The number is actually not crucial, but it seems unlikely that you ever need to generate a list with elements of varying but statically precisely known types, but that you don&#39;t statically know their number. **Question 1:** Could you even write such an example, e.g., in a loop? My intuition is that having a statically precise hlist with a statically unknown number of arbitrary elements (arbitrary relative to a given class hierarchy) just isn&#39;t compatible.

### HLists vs. Tuples

If this is true, i.e, you statically know number and type - **Question 2:** why not just use an n-tuple? Sure, you can typesafely map and fold over an HList (which you can also, but **not** typesafely, do over a tuple with the help of ``productIterator``), but since number and type of the elements are statically known you could probably just access the tuple elements directly and perform the operations.

On the other hand, if the function ``f`` you map over an hlist is so generic that it accepts all elements - **Question 3:** why not use it via ``productIterator.map``? Ok, one interesting difference could come from method overloading: if we had several overloaded ``f``&#39;s, having the stronger type information provided by the hlist (in contrast to the productIterator) could allow the compiler to choose a more specific ``f``. However, I am not sure if that would actually work in Scala, since methods and functions are not the same.

### HLists and user input

Building on the same assumption, namely, that you need to know number and types of the elements statically - **Question 4:** can hlists be used in situations where the elements depend on any kind of user interaction? E.g., imagine populating an hlist with elements inside a loop; the elements are read from somewhere (UI, config file, actor interaction, network) until a certain condition holds. What would the type of the hlist be? Similar for an interface specification getElements: HList[...] that should work with lists of statically unknown length, and that allows component A in a system to get such a list of arbitrary elements from component B.
 
  [1]: https://github.com/milessabin/shapeless
  [2]: https://stackoverflow.com/questions/11815908/valid-type-casting-of-both-covariant-and-contravariant-class-at-runtime-in-scala
  [3]: https://chat.stackoverflow.com/rooms/14938/discussion-between-mhs-and-edmondo1984

All Hlist Solutions on Gang of Coders

Total of 1 Hlist Solutions

Are HLists nothing more than a convoluted way of writing tuples?