Here's how I learned about kinds in an ML context: - Types that either take no parameters or have all their parameters applied have kind "*". - Generic types that expect one parameter have kind "* => *". They're like a function, they take one type (of kind "*") as input and produce a type (of kind "*"). For example, List can take Int as input and produce the type List[Int], or it can take String as input and produce List[String], and so on. - Generic types that take two arguments have kind "(*, *) -> *". Note that types are not curried in Scala; they are in ML and Haskell. - Generic types that take one-argument generics as an argument have kind "(STAR -> STAR) -> STAR". For example, your Functor and Monad examples: you had "trait/class Functor[F[_]]", so Functor takes a type F as argument, where F itself takes one type as an argument. So F is of kind "STAR -> STAR", and Functor takes an F and produces a type, so Functor has kind "[The-kind-of-F] -> STAR", or "(STAR -> STAR) -> STAR". [edit: turn "*" into "STAR" such that youtube doesn't bold the paragraph. Thanks, youtube.] - And so on. - If you represent kinds as a tree with "*" as leaves and arrows as inner nodes, your "kind level" concept equals the height of this tree, at least if all right subtrees are arrow-free. But note, here's a tree: "* -> (* -> *)". I think this kind is inexpressible in current Scala? I look at the Monad example with type lambdas, and it got me thinking: what can you express with type lambdas that you couldn't express with kind projection? Actually, the first thing I thought was "why can't I use underscore for kind projection?" So the syntax would be e.g. "Class EitherMonad[E] extends Monad[Either[E, _]] { ... }". The rule would be that an application of a generic type to some "_" type arguments is a type with n arguments where n is the number of underscores, filled in left to right. I expect the kind projector to do exactly this, but with '?'. Underscore already means wildcard/unspecified in Scala, using it here seems a natural fit? What problems does it run into? This example also suggests an answer to my previous questions: If you have a type "T[U[_, _]]" that is the same as "T[[A, B] =>> U[A, B]]" if I understood correctly. This means you can't express "T[[A, B] =>> U[B, A]]" with kind projection, since the order is left-to-right. Is "[T] =>> [U] =>> Either[T, U]" a valid thing in Scala 3? In Scala 2 you can do "{ type T[A] = blah }#T", so I guess we're used to apply type arguments interleaved with selecting type members. I guess the logic of the type system doesn't become less solvable or anything if type member selection is taken out of the process, and you can directly say "MyTypeLambda[ConcreteT][ConcreteU]"? Out of curiousity, would using the already familiar "=>" instead of "=>>" cause any logical problems? Was that a constrained or free decision, and in the latter case what was the basis for the decision?
Wow, there's a lot in here. Let me add some (short) color: 1 - The underscore is already quite overloaded (see blog.rockthejvm.com/underscore-in-scala/ ), there's a balance between using a familiar symbol and having a new symbol ('?'), and I suspect the Scala team chose '_' for a better fit. 2 - You can only express `T[[A, B] =>> U[B, A]]` explicitly. The underscores indeed assume left-to-right. 3 - Curried type lambdas are legal in Scala 3. 4 - I think there would have been confusions between A => B as a function type and A => B as a type lambda, so a new symbol was needed.
Cool video, and again it boils down to functions. Type lambdas or in this case partially applied types work exact the same as partially applied functions but a the type level. You apply types to the type constructor until you get back a partially applied type constructor with the remaining holes/types you need. I like the kind projector which just generates the ugly lambda code for me. Having this natively in the language is even cooler. Can't wait to adopt scala 3. Next video stack safety and trampolines 🤪?
Nice video. The type lambda syntax is greatly improved. In Scala 2.x it looked like this class EitherMonad[E] extends Monad[({type IntEither[A] = Either[Int, A]})#IntEither]
Hello, great video. These video series is like Netflix series, it ends one chapter and you want the next one.
Glad it feels like it!
Here's how I learned about kinds in an ML context:
- Types that either take no parameters or have all their parameters applied have kind "*".
- Generic types that expect one parameter have kind "* => *". They're like a function, they take one type (of kind "*") as input and produce a type (of kind "*"). For example, List can take Int as input and produce the type List[Int], or it can take String as input and produce List[String], and so on.
- Generic types that take two arguments have kind "(*, *) -> *". Note that types are not curried in Scala; they are in ML and Haskell.
- Generic types that take one-argument generics as an argument have kind "(STAR -> STAR) -> STAR". For example, your Functor and Monad examples: you had "trait/class Functor[F[_]]", so Functor takes a type F as argument, where F itself takes one type as an argument. So F is of kind "STAR -> STAR", and Functor takes an F and produces a type, so Functor has kind "[The-kind-of-F] -> STAR", or "(STAR -> STAR) -> STAR". [edit: turn "*" into "STAR" such that youtube doesn't bold the paragraph. Thanks, youtube.]
- And so on.
- If you represent kinds as a tree with "*" as leaves and arrows as inner nodes, your "kind level" concept equals the height of this tree, at least if all right subtrees are arrow-free. But note, here's a tree: "* -> (* -> *)". I think this kind is inexpressible in current Scala?
I look at the Monad example with type lambdas, and it got me thinking: what can you express with type lambdas that you couldn't express with kind projection?
Actually, the first thing I thought was "why can't I use underscore for kind projection?" So the syntax would be e.g. "Class EitherMonad[E] extends Monad[Either[E, _]] { ... }". The rule would be that an application of a generic type to some "_" type arguments is a type with n arguments where n is the number of underscores, filled in left to right. I expect the kind projector to do exactly this, but with '?'. Underscore already means wildcard/unspecified in Scala, using it here seems a natural fit? What problems does it run into?
This example also suggests an answer to my previous questions: If you have a type "T[U[_, _]]" that is the same as "T[[A, B] =>> U[A, B]]" if I understood correctly. This means you can't express "T[[A, B] =>> U[B, A]]" with kind projection, since the order is left-to-right.
Is "[T] =>> [U] =>> Either[T, U]" a valid thing in Scala 3? In Scala 2 you can do "{ type T[A] = blah }#T", so I guess we're used to apply type arguments interleaved with selecting type members. I guess the logic of the type system doesn't become less solvable or anything if type member selection is taken out of the process, and you can directly say "MyTypeLambda[ConcreteT][ConcreteU]"?
Out of curiousity, would using the already familiar "=>" instead of "=>>" cause any logical problems? Was that a constrained or free decision, and in the latter case what was the basis for the decision?
Wow, there's a lot in here. Let me add some (short) color:
1 - The underscore is already quite overloaded (see blog.rockthejvm.com/underscore-in-scala/ ), there's a balance between using a familiar symbol and having a new symbol ('?'), and I suspect the Scala team chose '_' for a better fit.
2 - You can only express `T[[A, B] =>> U[B, A]]` explicitly. The underscores indeed assume left-to-right.
3 - Curried type lambdas are legal in Scala 3.
4 - I think there would have been confusions between A => B as a function type and A => B as a type lambda, so a new symbol was needed.
Thank you! I've read about these a few times but didn't really get it until now.
Glad it clicked!
Now that's powerful content by scala master. Thanks!!!! and please upload video for microservices in scala..humble request by Fan!!!!!!
Will do! Lots of ideas for videos, so you'll definitely see something on this front.
Nice work Daniel! Hope you will release a course on Scala 3 :-)
Definitely!
Really good content, subscribed!
Thanks! Just getting started
Thank you!
Cool video, and again it boils down to functions. Type lambdas or in this case partially applied types work exact the same as partially applied functions but a the type level. You apply types to the type constructor until you get back a partially applied type constructor with the remaining holes/types you need. I like the kind projector which just generates the ugly lambda code for me. Having this natively in the language is even cooler. Can't wait to adopt scala 3. Next video stack safety and trampolines 🤪?
Lots of topics upcoming!
really cool
Nice video. The type lambda syntax is greatly improved. In Scala 2.x it looked like this class EitherMonad[E] extends Monad[({type IntEither[A] = Either[Int, A]})#IntEither]
Yep, we have it in the article version.
Feel like I'm watching magical spells written by a wizard. Difficult, but enjoyable.
As someone who wrote a library translating Monads and stuff from Haskell to Java, I'm jealous.
Everybody gangsta until Light Mode IntelliJ