Hacker News new | ask | show | jobs
by pcwalton 3884 days ago
Yeah, I shouldn't have made it read like I was equating the two. What HKT means is that typeclasses, like Monad, can take parameters of higher kinds. But if you don't have typeclasses in the first place (like D doesn't), then you don't have HKT.
1 comments
SamReidHughes 3884 days ago
Well this is completely wrong. HKT's have nothing to do with type classes.
link
pcwalton 3883 days ago
I'm referring to what people want when they say they want "higher-kinded types" in Rust. That is: the ability to have typeclasses with higher-kinded type parameters.

I'm well aware that the formal definition of an HKT is just a type with a higher kind, and that's irrelevant to this discussion.

link
SamReidHughes 3883 days ago
What certain Rust users want to do with HKT can already be done with D (maybe they're LKT's, loosely-kinded types -- you heard it here first!) or, for example, quite explicitly, C++, without type classes, so it's quite relevant.
link
pcwalton 3883 days ago
No, it's not relevant. When people say they want HKT, what they mean is that they want to create typeclasses that abstract over types of a higher kind and only those types, with a type system that can make those guarantees.

Saying C++ has HKT because it doesn't have typeclasses is like saying Python has all of Haskell's type system features because it doesn't have static types. There's a sort of vacuous sense in which it's true, but it's not a particularly meaningful or interesting thing to say.

link
SamReidHughes 3883 days ago
We have proof in this very thread that people don't use the term HKT that way. That makes sense, because that's not what the words "higher kinded types" mean.

> Saying C++ has HKT because it doesn't have typeclasses

I didn't say anything like that at all. C++ has HKT, and it doesn't have type classes.

link
Manishearth 3883 days ago
If you consider `template<template ...>` to be HKT then Rust has this too. Rust macros can be used like C++ templates (minus autoinstantiation) and they can take other macros as parameters. It's not as nice as C++, but ... workable.

Patrick is talking about HKTs which can be typechecked at the source, similar to the rest of Rust generics, when he talks about "they want to create typeclasses that abstract over types of a higher kind and only those types". C++ templates get typechecked at use-time, not instantiation-time, like Rust macros. On the other hand, Rust forces you to constrain types in generics (a la C++ "concepts") so that it typechecks at the source (and then the contract for types being passed into the function is clear in the signature). We don't have higher kinded bounds, though.

HKT, after all, is a comment on bounds. What sort of things are you allowed to substitute for this generic or template parameter?

What seems to be happening here is a difference of opinion on what constitutes a "bound", in the C++ world a "structural" bound (i.e. type vs number vs template) is all you have. In the Rust world this isn't considered a bound, since the bound isn't type-safe. In the Rust world, Haskell world, and most other worlds where the word "kind" is used, a bound is a "type" (typeclass) bound and is type safe -- you can only do operations on the parameter which the bounds let you. Many Rust/Haskell people would consider C++ templates to be a particularly awesome macro system (but not a generics system); since they're structural-bound (like Rust macros); not type-safe.

Really a matter of terminology though.

link