Is F -bound polymorphism useful?

Language Design
5

The language.higherKinds import was introduced in 2.10 since at the time there was still some uncertainty about the stability of higher-kinded types in Scala. I could not explain it better than the doc-comment:

  /** Only where this flag is enabled, higher-kinded types can be written.
   *
   *  '''Why keep the feature?''' Higher-kinded types enable the definition of very general
   *  abstractions such as functor, monad, or arrow. A significant set of advanced
   *  libraries relies on them. Higher-kinded types are also at the core of the
   *  scala-virtualized effort to produce high-performance parallel DSLs through staging.
   *
   *  '''Why control it?''' Higher kinded types in Scala lead to a Turing-complete
   *  type system, where compiler termination is no longer guaranteed. They tend
   *  to be useful mostly for type-level computation and for highly generic design
   *  patterns. The level of abstraction implied by these design patterns is often
   *  a barrier to understanding for newcomers to a Scala codebase. Some syntactic
   *  aspects of higher-kinded types are hard to understand for the uninitiated and
   *  type inference is less effective for them than for normal types. Because we are
   *  not completely happy with them yet, it is possible that some aspects of
   *  higher-kinded types will change in future versions of Scala. So an explicit
   *  enabling also serves as a warning that code involving higher-kinded types
   *  might have to be slightly revised in the future.
   *
   *  @group production
   */
  implicit lazy val higherKinds: higherKinds = languageFeature.higherKinds

Things did change for higher klnds (e.g. SI-2712, new syntax for type lambdas) but much less than one
might have anticipated. Dotty and Scala-2 have by-and-large the same treatment of higher-kinded types. So I believe the language import should no longer be required (and in fact it isn’t required in Dotty).

F-bounds do indeed add significant complexity. I would love to be able to get rid of them, and replace them with higher-kinded subtyping in the way it is done in the TGrid example. But I don’t know how to handle the breakage of compatibility and Java interop. That looks like a daunting problem.

5 Likes