3 ms·

Actually higher kinded types are easier than "generic associated types". All things associated type related play less nice with type inference, and in fact Has

Actually higher kinded types are easier than "generic associated types". All things associated type related play less nice with type inference, and in fact Haskell's associated types are seriously flawed and needs to overhauled. I don't know why Rust doesn't got for HKTs. It would be relatively easy, and they have often have much nicer error messages than associated types.

steveklabnik 6y ago
I didn't say one or the other was easier, just that extending a type system like Rust's with an attitude towards stability like Rust's is not simple. > I don't know why Rust doesn't got for HKTs. In my understanding, the benefits are less clear. You don't just get Monad for free because you have HKTs. ATC/GATs are much more clearly needed.
- Ericson2314 6y ago
  You indeed don't get Monad for free, we're in agreement. To pick a use case dear to Rust, it's definitely the best way to e.g. write data structures that are parameterized over say Rc, Arc, or some Gc. Again, I say "the best" with pedagogy and productivity in mind: the error messages are better and intent clearer with this mechanism over the associated type alternatives.
comex 6y ago
> Actually higher kinded types are easier than "generic associated types". Rust leans heavily on associated types in general, and there are several concrete use cases where generic associated types are sorely missed (especially involving lifetimes). You might ask, why not both? Part of the reason is conservatism about language features, and wanting 'only one way to do it'. But another part is that Rust is starved for compiler implementation manpower. The current generic associated types RFC was proposed in 2016 and merged in 2017, and it's a highly prioritized feature. But implementation work didn't even start until sometime in 2019 (AFAIK), and it still has a ways to go. There's also another, somewhat more mundane problem... Higher-kinded types somewhat conflict with default type parameters. If you have struct Foo<T = i32> { t: T } then you can currently write Bar<Foo> and it's equivalent to Bar<Foo<i32>>. So how do you distinguish that from passing the Foo constructor itself? It may be possible to just distinguish based on context, but it's an issue.
- Ericson2314 6y ago
  I'm all for having generic associated types too, but by your own argument > Part of the reason is conservatism about language features, and wanting 'only one way to do it But for the things HKTs are good for, it's much more usable: easy to teach, simpler errors. Dare I say HKT is the conservative choice. > But another part is that Rust is starved for compiler implementation manpower. That's a bummer, and I wish you the best in finding new sources of funding. But if HKT is easier, that's another reason to do it first. > There's also another, somewhat more mundane problem... I don't think either of us thinks that is insurmountable :)

steveklabnik 6y ago

I didn't say one or the other was easier, just that extending a type system like Rust's with an attitude towards stability like Rust's is not simple. > I don't know why Rust doesn't got for HKTs. In my understanding, the benefits are less clear. You don't just get Monad for free because you have HKTs. ATC/GATs are much more clearly needed.

Ericson2314 6y ago
You indeed don't get Monad for free, we're in agreement. To pick a use case dear to Rust, it's definitely the best way to e.g. write data structures that are parameterized over say Rc, Arc, or some Gc. Again, I say "the best" with pedagogy and productivity in mind: the error messages are better and intent clearer with this mechanism over the associated type alternatives.

comex 6y ago

> Actually higher kinded types are easier than "generic associated types". Rust leans heavily on associated types in general, and there are several concrete use cases where generic associated types are sorely missed (especially involving lifetimes). You might ask, why not both? Part of the reason is conservatism about language features, and wanting 'only one way to do it'. But another part is that Rust is starved for compiler implementation manpower. The current generic associated types RFC was proposed in 2016 and merged in 2017, and it's a highly prioritized feature. But implementation work didn't even start until sometime in 2019 (AFAIK), and it still has a ways to go. There's also another, somewhat more mundane problem... Higher-kinded types somewhat conflict with default type parameters. If you have struct Foo<T = i32> { t: T } then you can currently write Bar<Foo> and it's equivalent to Bar<Foo<i32>>. So how do you distinguish that from passing the Foo constructor itself? It may be possible to just distinguish based on context, but it's an issue.

Ericson2314 6y ago
I'm all for having generic associated types too, but by your own argument > Part of the reason is conservatism about language features, and wanting 'only one way to do it But for the things HKTs are good for, it's much more usable: easy to teach, simpler errors. Dare I say HKT is the conservative choice. > But another part is that Rust is starved for compiler implementation manpower. That's a bummer, and I wish you the best in finding new sources of funding. But if HKT is easier, that's another reason to do it first. > There's also another, somewhat more mundane problem... I don't think either of us thinks that is insurmountable :)