A friend of mine posed a seemingly innocuous Scala language question last week that I didn&#39;t have a good answer to: whether there&#39;s an easy way to declare a collection of things belonging to some common typeclass.  Of course there&#39;s no first-class notion of &quot;typeclass&quot; in Scala, so we have to think of this in terms of traits and context bounds (i.e. implicits).

Concretely, given some trait `T[_]` representing a typeclass, and types `A`, `B` and `C`, with corresponding implicits in scope `T[A]`, `T[B]` and `T[C]`, we want to declare something like a `List[T[a] forAll { type a }]`, into which we can throw instances of `A`, `B` and `C` with impunity.  This of course doesn&#39;t exist in Scala; a [question last year](https://stackoverflow.com/questions/7213676/forall-in-scala) discusses this in more depth.

The natural follow-up question is &quot;how does Haskell do it?&quot;  Well, GHC in particular has a type system extension called [impredicative polymorphism](http://www.haskell.org/ghc/docs/latest/html/users_guide/other-type-extensions.html#impredicative-polymorphism), described in the [&quot;Boxy Types&quot;](http://research.microsoft.com/en-us/um/people/simonpj/papers/boxy/boxy-icfp.pdf) paper.  In brief, given a typeclass `T` one can legally construct a list `[forall a. T a =&gt; a]`.  Given a declaration of this form, the compiler does some dictionary-passing magic that lets us retain the typeclass instances corresponding to the types of each value in the list at runtime.

Thing is, &quot;dictionary-passing magic&quot; sounds a lot like &quot;vtables.&quot;  In an object-oriented language like Scala, subtyping is a much more simple, natural mechanism than the &quot;Boxy Types&quot; approach.  If our `A`, `B` and `C` all extend trait `T`, then we can simply declare `List[T]` and be happy.  Likewise, as Miles notes in a comment below, if they all extend traits `T1`, `T2` and `T3` then I can use `List[T1 with T2 with T3]` as an equivalent to the impredicative Haskell `[forall a. (T1 a, T2 a, T3 a) =&gt; a]`.

However, the main, well-known disadvantage with subtyping compared to typeclasses is tight coupling: my `A`, `B` and `C` types have to have their `T` behavior baked in.  Let&#39;s assume this is a major dealbreaker, and I *can&#39;t* use subtyping.  So the middle ground in Scala is pimps^H^H^H^H^Himplicit conversions: given some `A =&gt; T`, `B =&gt; T` and `C =&gt; T` in implicit scope, I can again quite happily populate a `List[T]` with my `A`, `B` and `C` values...

... Until we want `List[T1 with T2 with T3]`.  At that point, even if we have implicit conversions `A =&gt; T1`, `A =&gt; T2` and `A =&gt; T3`, we can&#39;t put an `A` into the list.  We could restructure our implicit conversions to literally provide `A =&gt; T1 with T2 with T3`, but I&#39;ve never seen anybody do that before, and it seems like yet another form of tight coupling.

Okay, so my question finally is, I suppose, a combination of a couple questions that were previously asked here: [&quot;why avoid subtyping?&quot;](https://stackoverflow.com/questions/7266596/why-avoid-subtyping) and [&quot;advantages of subtyping over typeclasses&quot;](https://stackoverflow.com/questions/3848492/advantages-of-subtyping-over-typeclasses) ... is there some unifying theory that says impredicative polymorphism and subtype polymorphism are one and the same?  Are implicit conversions somehow the secret love-child of the two?  And can somebody articulate a good, clean pattern for expressing multiple bounds (as in the last example above) in Scala?

All Impredicativetypes Solutions on Gang of Coders

Total of 1 Impredicativetypes Solutions

Impredicative types vs. plain old subtyping