[rust-dev] std::num::pow() is inadequate / language concepts
[The previous message got sent accidentally by gmail]
However, for performance reasons, I think some kind of trait overloading
would be nice.
i.e., you should be able to do
impl Trait for A<φ> { ... }
overload impl Trait for A<φ[int/T]> {
//...
}
And when using (x : Trait) the items in the overload impl will be used
instead of the items in the base impl (note that, except for associated
types, overloaded traits won't participate in name resolution/type checking
- so probably force associated types in the overload to be the same as the
base).
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] std::num::pow() is inadequate / language concepts
std::num::pow is not the most general exponentiation function but a second-rate utility function in the standard library - you don't have to use it. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] std::num::pow() is inadequate / language concepts
On 26/07/14 12:56 PM, Patrick Walton wrote: > On 7/26/14 5:54 AM, SiegeLordEx wrote: >> While this doesn't matter for the pow function (the alternate function >> would just have a different path/name), it matters for the special >> syntaxes. When the Iterator is no longer enough for you (there was a >> case like this in IRC recently involving mutable windows), then you have >> to abandon the for loop which is a big syntactic change (right now it >> works because it is ad-hoc). > > As of last week it's not anymore. > >> Similarly, when the operator overloading >> traits are insufficient, then you have to abandon that sugar as well. >> One might say "well, don't use those traits then" but that's not what >> happens in practice. In practice, people want the syntax sugar and >> therefore are guided into inefficiency. Some of BigNum's operator >> overloads shouldn't exist because they are so inefficient, and yet they >> do because people expect BigNum to act (on a syntactic level) just like >> any other number. >> >> So I think this is a real problem with real solutions that don't require >> going down the ad-hoc template black hole. > > Well, part of the problem here is that people are going to want to write > generic functions that take addable values. If we start making `+` and > friends overloadable/ad-hoc, then people are going to be surprised when > they can't pass (say) bignums to functions that want addable things. > > Patrick We can start out with efficient generic code for bignums (meaning stuff like `op(&mut tmp, &a, &b)` in a loop with a reused temporary variable) and then add a "static" branch + other code for primitives as vector iterators already do for zero-size types. Ideally there would be a way of expressing it without relying on optimizations to remove a branch but the language is expressive enough other than that. signature.asc Description: OpenPGP digital signature ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] std::num::pow() is inadequate / language concepts
On 07/26/2014 12:56 PM, Patrick Walton wrote: Well, part of the problem here is that people are going to want to write generic functions that take addable values. If we start making `+` and friends overloadable/ad-hoc, then people are going to be surprised when they can't pass (say) bignums to functions that want addable things. The current Rust doesn't allow a complete lack of surprise. Either you will be surprised by the traits not being supported by every numeric type, or you will be surprised by the terrible performance of most types that implement Op. The core issue is that 'addable' (and other concepts/functions) cannot be expressed efficiently for all types in some unified way. -SL ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] std::num::pow() is inadequate / language concepts
On 7/26/14 5:54 AM, SiegeLordEx wrote: While this doesn't matter for the pow function (the alternate function would just have a different path/name), it matters for the special syntaxes. When the Iterator is no longer enough for you (there was a case like this in IRC recently involving mutable windows), then you have to abandon the for loop which is a big syntactic change (right now it works because it is ad-hoc). As of last week it's not anymore. Similarly, when the operator overloading traits are insufficient, then you have to abandon that sugar as well. One might say "well, don't use those traits then" but that's not what happens in practice. In practice, people want the syntax sugar and therefore are guided into inefficiency. Some of BigNum's operator overloads shouldn't exist because they are so inefficient, and yet they do because people expect BigNum to act (on a syntactic level) just like any other number. So I think this is a real problem with real solutions that don't require going down the ad-hoc template black hole. Well, part of the problem here is that people are going to want to write generic functions that take addable values. If we start making `+` and friends overloadable/ad-hoc, then people are going to be surprised when they can't pass (say) bignums to functions that want addable things. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] std::num::pow() is inadequate / language concepts
On 07/25/2014 01:04 PM, Patrick Walton wrote: I don't think we should be trying to solve it. I don't agree. If this problem is truly appreciated, then you have to conclude that completely generic code is not possible in Rust, which means that Rust should not bless particular generic signatures (the operator overloading traits, the iterator trait, maybe a few others I can't think of right now) with special syntax because they can't possibly be efficient in all cases. While this doesn't matter for the pow function (the alternate function would just have a different path/name), it matters for the special syntaxes. When the Iterator is no longer enough for you (there was a case like this in IRC recently involving mutable windows), then you have to abandon the for loop which is a big syntactic change (right now it works because it is ad-hoc). Similarly, when the operator overloading traits are insufficient, then you have to abandon that sugar as well. One might say "well, don't use those traits then" but that's not what happens in practice. In practice, people want the syntax sugar and therefore are guided into inefficiency. Some of BigNum's operator overloads shouldn't exist because they are so inefficient, and yet they do because people expect BigNum to act (on a syntactic level) just like any other number. So I think this is a real problem with real solutions that don't require going down the ad-hoc template black hole. Part of the solution has to involve changing how the language syntax sugar works. The other part, however, involves libraries: if the generic functions in libnum expect types to act as built-in types (by requiring T: Mul etc), then BigNum should not act like a built in type; alternatively, the generic functions in libnum should be overloadable (via the double-dispatch trick). Maybe there's some other library-based pattern that would work as well. -SL ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] resolving 'str'
Hello! I'm trying to make racer resolve '&str' types properly. I've read that the separation of type and value namespaces means you can refer both to the 'str' type and the 'str' module[1]. However I would have thought that the 'str' type lives in the type namespace, and according to the reference guide modules and types share the same namespace. How should racer resolve the type? Thanks v much, Phil [1] http://tomlee.co/2014/04/03/a-more-detailed-tour-of-the-rust-compiler/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
