7 ms·
There are already FP features and monads in Rust. What exactly do you want? It is unlikely you will ever see non-zero cost abstractions in idiomatic Rust.
by whyever 9y ago
There are already FP features and monads in Rust. What exactly do you want?
It is unlikely you will ever see non-zero cost abstractions in idiomatic Rust.
- fmap 9y agoCan you link to some documentation about how monads work in rust? Based on the sibling comment rust doesn't support higher-kinded types yet, so I'm interested in how you would encode this in rust.
- steveklabnik 9y agoRust does not have HKT, and so we cannot write a generic Monad. Rust has many instances of Monad, though. That said, at some point, we'll be getting ATC, which is equivalent to HKT in many cases, but feels more Rusty.
- ronjouch 9y agoThanks :) . Nit: less TLAs, please. - HKT: Higher-Kinded Types - ATC: Alternative Type Constructors
- steveklabnik 9y agoYeah, sorry. It's "Associated" not "Alternative" by the way. A good reason to spell them out ;)
- fmap 9y agoHow does your implementation of associated types differ from the same feature in Haskell? In particular, why is this related to higher-kinded types? From what I remember from the theory, higher-kinded types lead to a genuinely more difficult type inference problem (going from easy first-order unification to undecidable higher-order unification), while associated types are simply existential types (and in particular no more difficult than higher-rank polymorphism).
- steveklabnik 9y agohttps://github.com/rust-lang/rfcs/blob/master/text/1598-generic_associated_types.md https://github.com/rust-lang/rfcs/blob/master/text/1598-gene... has all the gory details, reading that is probably best!
- fmap 9y agoOk, I did, so here's the answer in case anybody else is confused: The feature under discussion is "associated type constructors". Rust already has associated types in traits (I didn't know that part and was confused), and what this feature adds is that it allows us to associate a first-order type constructor to a trait. Since the type constructor is first-order, and first-order type constructors are already present in the base language in the form of generic types, the implementation is simplified to the point that it can reuse the existing infrarstructure for type inference. --- Apart from that, the reason for this implementation choice seems to be that it's required for precise lifetime management. Almost all datastructures in rust seem to be parameterized with a lifetime argument, even if they have no further type parameters. Since there is no such thing as a second-order lifetime (i.e., a "lifetime constructor" T : (lifetime -> lifetime) -> lifetime), first-order type constructors are enough to handle all issues that pop up because of lifetime management. --- That actually seems like a very pragmatic design. The only problem I had while reading this RFC is that the combination of "multiple-inheritance" in traits with their built in namespacing leads to some really ugly syntax, e.g., "<T as Foo>::Bar<'a, 'static>;". Is this already idiomatic rust? There's several more things that confuse me in this RFC, but this is probably the wrong place to discuss these things. Incidentally, what is the right place to talk about this?
- steveklabnik 9y ago> Is this already idiomatic rust? It's only used for disambiguation cases, extremely rarely. I've been doing Rust almost five years and I think I may have written <T as Foo> once. > what is the right place to talk about this? https://internals.rust-lang.org/ https://internals.rust-lang.org/ is the best place. Probably going to be pretty slow-going until next week, due to the holiday today.
- fulafel 9y agoAren't many opt-in Rust abstractions non-zero-cost? Functions, the borrow checker and dynamic dispatch come to mind.
- steveklabnik 9y ago"zero-cost abstractions" means "zero extra cost". Everything has a cost. The borrow checker has zero runtime cost though, as it's entirely at compile time.
- fulafel 9y agoI meant to suggest that opt-in features for FP style programming might be accepted, since there doesn't seem to be an actual ban on non-zero-cost abstractions. Re "extra", I'm not sure what you mean - does it mean that the abstraction is implemented efficiently, but still has the cost that is usually associated with that abstraction? For example, dynamic dispatch is as fast as a DIY dynamic dispatch in assembly? The borrow checker, AFAIU, has a cost in that it forbids some (more efficient) shared data accesses that it can't prove safe but still are.
- whyever 9y ago> For example, dynamic dispatch is as fast as a DIY dynamic dispatch in assembly? Yes, zero cost means you could not implement it in a more efficient way by hand. > The borrow checker, AFAIU, has a cost in that it forbids some (more efficient) shared data accesses that it can't prove safe but still are. This is not what it meant with "cost" in this context. It is zero cost because it only runs at compile time. That it rejects some valid programs is irrelevant, because it is zero cost for the programs it accepts.
- fulafel 9y agoInteresting. But I think restricively molding what can be compiled can also be an abstraction cost. Maybe it's more one of those "you know it when you see it" things?