Good macro system is a must, indeed, that's very nice. Though just macro system is not enough.
In order to be useful a language should support a combo of HKTs, typeclasses (better implemented with implicits) _and_ macros with implicit materialization. Scala has that (and I'm using Scala) but it has some quirks and problems and I would be really happy to see something with these features but with fast compiler and separated from JVM.
HKTs are something like generics for generics, so no.
E.g. a method takes some input and returns some output that is a list can have integers or strings, so you use generics instead of the concrete type integer/string.
But what if your input type is not a list of CONCRETE_TYPE but instead a WRAPPER_TYPE of CONCRETE_TYPE? E.g. say you have a method that can sort not only lists but also sets or trees, where each of these collections can contain an arbitrary (but comparable) concrete type like integer or string.
This WRAPPER_TYPE which can be parametrized with one or more other types (either concrete types or other wrapper types of arbitrary shapes) encapsulates the concept of a higher kinded type (where a simple type like integer or string would be a low-kinded type in this lingo).
In that case, basic generics are unfortunately not sufficient to express this.
In practice this is used mostly in libraries by library authors to provide users flexibility. It is especially helpful to help with compatibility between libraries that don't know of each other in advance. But it is also very useful for application developers to model different implementations of services/abstractions that have different properties.
Yep, thanks. Though, unfortunately, that's very far from what I can have in Scala. Maybe I'm wrong but seems like that I can't express even basic primitives like functor or monoid using this language. That's sad.
You want this new language to implement a particular set of features in a similar way to a specific, named feature from Scala which they themselves are moving away from in 3.0?
> which they themselves are moving away from in 3.0?
Nope, they are not.
> specific, named feature from Scala
HKTs and typeclasses are not specific to Scala. Implicits and incoherense is, somehow, specific, though it seems to be lot, lot better than coherent implementation and that's why it stays in 3.0.
> You want this new language to implement a particular set of features
Yes, in 2021 it should be obvious that HKTs and typeclasses are must for engineers productivity. Also I can't comprehend how virtually everyone ignores insanely productive concept of implicit materializers. It's very unfortunate that language designers prefer to stick with old dead ideas and don't want to learn from Scala nor Haskell.
