Multiple type parameter lists in Dotty? (SI-4719)

I believe, that in Dotty the simplest solution for this particular case is with the new syntax of higher-order polymorphic functions

def pure[F[_]] (using P: Pure[F] ) = [A] => (a: A) => P.pure (a)

which then is used

pure[Option](1)

But, of course, multiple parameter lists could be very useful in other cases.

1 Like

This is working, isn’t it:

def [A, F[_] : Applicative](a: A).pure: F[A] = Applicative[F].pure(a)

1.pure
// Some(1)

Oh, indeed it is. It is working even better than before in terms of type inference. Thank you!

1.pure
// Some(1)

how particular F[_] was chosen there? What if there are several implicit Applicatives in scope?

1 Like

I’m getting inconsistent results but from what I’m seeing type inference got way better. If it can figure out the types it will pick one even if there are multiple implicits in scope. Only if it can’t it tells me that they are ambiguous. For instance this

val option: Option[Int] = 1.pure

works even if both the Applicative[Id] and the Applicative[Option] are in scope but the following obviously tells me that it doesn’t know which one to pick:

val option = 1.pure
1 Like

Perhaps if there were something like _ (like in list.reduce(_ + _)), but for types, that we could use to define type lambdas with anonymous parameters, this would be more feasible.

Those who need V be inferred are happy, but those two need K be inferred would need to define something like

type M[V][K] = Map[K, V]

That could be turned into just Map[$][V] where $ behaves something like _ and turns it into [K] =>> Map[K][V], making it similar to Map[K]

Edit: There’s a Pre-SIP for this already: Pre-SIP: using underscores for type lambdas

1 Like