High-order extension methods

It’s possible to define such an extension method

def[A, B, C] (f: A => B) o (g: B => C): A => C = a => g (f (a) )

but isn’t possible this:

extension on[A, B] (f: A => B) {
  def o[C] (g: B => C): A => C = a => g (f (a) )
}

In some cases, it could be useful to be able to define for some higher-order type extension methods with additional type parameters

4 Likes

In some cases, it could be useful to be able to define for some higher-order type extension methods with additional type parameters

Yes, and hopefully that will come at some point. To do this right we need to support multiple type parameter lists on methods, which is non-trivial. Before we get there I’d rather not do something
temporary (like merging parameter lists) since it would likely make it harder to do the right thing later.

For the moment, we have made sure that Tasty supports multiple type parameter lists. So we can upgrade later without changing the format.

4 Likes

Thank you, Martin.

My point is (I’m sure that’s clear for you, I’d like just to unfold some of my considerations), that in “old good” Scala we already can define higher-order extension methods with an implicit class:

implicit class FunOp[A,B](val f:A=>B) extends AnyVal {
  def o[C](g:C => A):C => B = c => f(g(c))
 // more extension methods ...
}

Now, in Dotty, we got a much more clean syntax for stand-alone extension methods and even, recently, a nice clause ‘extension on’ (and I like it pretty much, thank you!). So it would be a bit disappointing to fall back into “old school” Scala style any times when for some generic type there is needed a bunch of higher-order extensions. Of course, type-classes should help in such cases, but sometimes they are felt like a bit too heavy-weight.

While I understand, that there are some deep consequences on a type theory level, but it would be very nice to have a really simple and clear syntax for higher-order extension methods as well.

Thank you again, Martin!

3 Likes