6 ms·
Higher Kinded Types in Rust
- gpderetta 5y agoInteresting article but it is a bit funny that the author says that they are fed up with C++, then they try to hack around the lack of HKT :)
- bally0241 5y agoROFL, oh yes this is so much better and the syntax so much clearer than C++. ;)
- marcosdumay 5y agoHum... Even though C++ can do HKT with templates, it's not a convenient feature of the language. C++ is really not the language that comes to mind when somebody talks abut HKT.
- gpderetta 5y agoAs C++ features go, HKTs in the form of template arguments and templated associated types are fairly straightforward to use and understand. In fact we had usable type level lambdas before we got actual lambdas in the language. Of course, as the rest of templates there is no actual definition time type checking.
- nicoburns 5y agoGeneric Associated Types which provide a limited form of higher kinded types as a native language feature are pretty close to being stabilised now https://github.com/rust-lang/rust/issues/44265 https://github.com/rust-lang/rust/issues/44265 As always with Rust, work is released on an "when it's done" basis but estimates are pointing to some point in the first half of next year. While I'm on this topic, the other big rust feature that looks to be coming soon is the new non-llvm-specific inline asm syntax. A stabilisation PR has been opened, which entails a last check over before the feature flag to enable on stable is switched (followed by a 6-12 week lag until it actually hits stable while it rides the release trains): https://github.com/rust-lang/rust/pull/91728 https://github.com/rust-lang/rust/pull/91728
- asimpletune 5y agoYeah I feel like rust’s avoidance of HKT, I assume in the name of them being “hard” or confusing (try explain to someone what a monad is), just in turn reinforced why they exist. So many things would be easier if there weren’t these half measures.
- kortex 5y agoHard/confusing for user programmers, or for language designers? I don't think the concept being tricky for users is what is preventing adoption of HKTs. The &|x| hints at some of the reasons why implementing HKTs in Rust is tricky (not impossible). They are naturally very abstract, and if a structure is to be compiled in Rust, it (and its lifetime) needs to be reified. That is no small feat. See also: the difficulty with callbacks/anonymous closures in Rust.
- asimpletune 5y agoYeah that’s a good point. I don’t really know the real reasons. Maybe it’s just hard to do it and to have the 0 cost abstractions? Hopefully not impossible though.
- ReleaseCandidat 5y agoYes, I'd too prefer HKT in Rust. And a GC. And getting rid of all those superfluous braces, parens and semicolons. And instead of 'Rust' (WTF?) we could name it after a mathematician - why not e.g. Moses? :D
- gpderetta 5y agoYou could add lazy evaluation and call your language Curry.
- ReleaseCandidat 5y agoOh yes, I forgot about that!
- choeger 5y agoSchönfinkel, please.
- sargstuff 5y ago3pt iterators called Steph would be more interesting, but that'd be beyond the arc of this thread.
- kortex 5y agoThis feels unnecessarily snarky. If you wanna write in Haskell, use Haskell. Rust is a different beastie with different use cases. There's no reason why any language shouldn't benefit from a powerful type system if they can manage it.
- ReleaseCandidat 5y ago> There's no reason why any language shouldn't benefit from a powerful type system if they can manage it. There actually is. If you mix too many low- and high-level (abstract) features you get something like C++. Apart from that, Rust already takes _long_ to compile. I do _not_ want to solve Haskell-problems in Rust or Rust-problems in Haskell.
- dgb23 5y agoI'm a complete buffoon when it comes to type theory. Would appreciate some help to understand what is going on here. I tried to search the article for a rationale. I only found "beloved" and "elegant" as motivators. Can someone give me a clear, understandable rationale and example? What problem would higher kinded types solve in Rust? I have trouble thinking purely in terms of abstraction, when I can't relate a process to some kind of goal. I also thank the author for the "braindamage" warning. Unfortunately I already had a metaphorical stroke way before that. The author acknowledges that the exercise was "not attractive" in the end, because of syntactical noise and lack of coherent type checking. What would a correct and useful implementation of this achieve?
- throwaway17_17 5y agoI don’t know if I can do an example in a common enough syntax to make sense. However, the general/basic example for higher kinded types is usually a Collection<T> vs a List<T>. The List take some type T (i.e. int, float, char) and is a list of ‘objects’ of that type. Every ‘object in the list is an int. A Collection<T> is a collection of some type <T<T2>> (i.e. list<T>, option<U>, vector<V>). This allows for the collection to be composed of ‘objects’ whose types are each some List<T> where each objects T can be different. So a Collection<List<T>> could be a list of [List<int>, List<float>, List<char>]. I think the jargony statement is that higher kinded types allow for a type to abstract over types which take another type as a constructor. From my perspective the rationale for higher kinded type is usually the drive/goal of having as high a ceiling for abstraction as possible and create ‘reusable’ and generic code over and above what is available without higher kinded types.
- dgb23 5y agoTy! As the user of said collection: Are the underlying objects inferred when I look at them one by one?
- throwaway17_17 5y agoI would not expect the T type in a Collection<List<T>> to be used in a way where inference would be an issue. Typically, the type system would use parametric polymorphism to just deal with the Collection and then probably ‘pattern-match’ on the type inside a list.