Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
@Demolishun I'll need to test whether C++'s generic nested class support can be used to represent HKTs.
-
atheist99912yI think given C++ templates are turning complete, yes. As to whether it's simple/easy, that's a different question...
-
@atheist HKTs are constraints on parametric types that can be expressed for the parametric types themselves rather than any particular parametrization. The most iconic example is Monad, which specifies the existence of the following function (called bind) on any implementing type M:
Fn(M<T>, Fn(T) -> M<U>) -> M<U>
Monad can't be enforced on M<T> for arbitrary T, but must be enforced on M itself. The difference can be seen if you try to express it as a virtual base class or an interface in an OO language like C# or TS. -
It's technically possible to translate HKTs into regular types, but it's a very hacky solution and you lose type checking for arbitrary T (you get type checking on the particular instantiations that exist in your codebase instead).
-
@DeepHotel I'll try.
Types are present in Python and Javascript as well, you just don't write them out. Interfaces also exist in these languages as well, only, again, they're implicit. A thing that walks, swims and squawks is an instance of the Duck interface, and a function that tries to make its argument swim and squawk expects an instance of the Duck interface. You just won't know that you should've implemented this interface, or that the function expected swim() to return true if the swimming was successful, until a property error crashes your production app. This is also why I hate languages that lack static type checking.
1/2 -
A type, in the broadest of terms, whether that be a class or interface, describes what you can do with a value. A higher-kinded type describes what you can do with a type. For instance, Dictionary is a Functor, which means that you can map over it with a function that transforms the current values into new ones. You can map over other types as well, such as List. List is also a Monad, which means that you can flatten a List that contains Lists into a single List of the inner nested values. This additionally means that you can also map over it with a function that returns Lists of final values. These operations are called flatten and flatmap, and they're defined for a lot of interesting types such as Option in nullsafe languages. Functor and Monad are HKTs, because they make general statements about types, not values. You can't flatten an Option of List. This operation exists for each and every type of Monad separately.
2/2 -
I won't be able to explain how GATs are connected to HKTs as this requires a lot of Rust-specific context.
Related Rants
Generic associated types are getting stabilized in Rust! Higher kinded types here we come!
rant
rust
hkts
generic associated types
functional