On 2014-07-24 16:30, Kevin Ballard wrote:
On Wed, Jul 23, 2014, at 12:52 PM, David Henningsson wrote:
On 2014-07-21 19:17, Patrick Walton wrote:
On 7/21/14 8:49 AM, Tobias Müller wrote:
Patrick Walton pcwal...@mozilla.com wrote:
On 7/20/14 8:12 PM, David Henningsson wrote:
From a
Hi Patrick,
If the signature is wrong and we mistakenly freeze it, we can just introduce
a new function with a different name.
But this is a severe design issue, to introduce new function names. This makes
generic programming impossible. Now the user has to distinguish between
the types, but
On 07/24/2014 06:46 PM, Gregor Cramer wrote:
1. Overloading is not supported (even the archaic C++ is providing this).
I should note that Rust provides a limited form of overloading via the
trait-double dispatch trick:
trait PowImplRes
{
fn pow(self, exp: uint) - Res;
}
fn powRes,
Hi all,
I have an idea about data types here.
We have two `product types` here, tuples and structs, but only one `sum types`,
which is `enum`.
The tuple's members have anonymous names. There is a missing type which is `sum
type`with anonymous members.
Why shouldn't we have another simpler
Hi Marijn,
Firstly, blanket statements like This makes generic programming
impossible and it does not allow proper software design are
unneccesary hyperbole, and do not help the discussion in any way.
You're not right, my statement wasn't blanket, it was my result
after I tried to overwork
For the specific issue of exponentiation, you might be interested in
https://github.com/rust-lang/rfcs/pull/172
On Fri, Jul 25, 2014 at 9:26 AM, Gregor Cramer rema...@gmx.net wrote:
Hi Marijn,
Firstly, blanket statements like This makes generic programming
impossible and it does not
Sorry... I meant a^8 xD...
And overlaoding is not a great concept in general, IMO.
What Rust could do is copy template specialization. So that I can say:
pub fn powT: One + MulT, T(mut base: T, mut exp: uint) - T; //
uses the exponential trick
pub fn powi64(mut base: i64, mut exp: uint) - i64;
On 7/25/14 6:26 AM, Gregor Cramer wrote:
And so the function call is as expected, like with other numeric types:
pow(a) // a is BigInt
But there is now a problem in this function definition, BigInt is given as
a copy, and this is a software design issue (superfluous memory allocation).
And
On 7/25/14 4:43 AM, SiegeLordEx wrote:
Yes, I concur on most of these points and I've brought up some related
points before. The operator overloading technique used by Rust is
antithetical to efficient generic code. The core numeric traits and
functions are currently designed only with built-in
On Fri, Jul 25, 2014 at 10:04 AM, Patrick Walton pcwal...@mozilla.com wrote:
Neither auto-ref or ad-hoc operator overloading
would let you write a generic function that calls
`pow` and works optimally with both bigints and
ints. I think the only thing that would work is
something like C++
Did I miss a point in this thread where using a typeclass/trait to
implement exponentiation was dismissed?
This function could be changed to:
fn powT: HasPow(base: T, exp: uint) - T { base.pow(exp) }
trait HasPow {
fn pow(self: Self, exp: uint) - Self
}
Or, just use HasPow in your code.
Why
On 7/25/14 10:11 AM, Oscar Boykin wrote:
Did I miss a point in this thread where using a typeclass/trait to
implement exponentiation was dismissed?
This function could be changed to:
fn powT: HasPow(base: T, exp: uint) - T { base.pow(exp) }
trait HasPow {
fn pow(self: Self, exp: uint) -
On 7/25/14 10:10 AM, Josh Haberman wrote:
On Fri, Jul 25, 2014 at 10:04 AM, Patrick Walton pcwal...@mozilla.com wrote:
Neither auto-ref or ad-hoc operator overloading
would let you write a generic function that calls
`pow` and works optimally with both bigints and
ints. I think the only thing
Did I miss a point in this thread where using a typeclass/trait to
implement exponentiation was dismissed?
This function could be changed to:
fn powT: HasPow(base: T, exp: uint) - T { base.pow(exp) }
trait HasPow {
fn pow(self: Self, exp: uint) - Self
}
Or, just use HasPow in your
I gave up at all. (I'm doing software design and implementation since
more than 30 years, and I never accept compromises, this is the way
how to develop magnificient software).
Hum, I would almost strongly disagree I would even go as far as
saying that you won't develop any kind ...
On Fri, Jul 25, 2014 at 3:36 PM, Gregor Cramer rema...@gmx.net wrote:
I don't care about the capabilities of other languages, I don't use a
language if it is not appropriate.
Appropriate for what? You seem to be claiming that stable code in
general needs this feature, so that's consigning all
How can you disagree about what I'm doing?
I don't. I disagree with that: I never accept compromises, this is
the way how to develop magnificient software
Because it's not. Unless you use magnificient only in academic context.
I don't care about the capabilities of other languages, I don't
And of course it's possible to change something to a trait after the
fact without breaking API compatibility.
How you are doing this? I'm in fact a newbie in Rust, and it's interesting
that this can be done. std::num::pow() is a good example, I think.
Suppose I already have a program which is
On Fri, Jul 25, 2014 at 1:45 PM, Gregor Cramer rema...@gmx.net wrote:
How you are doing this? I'm in fact a newbie in Rust, and it's
interesting
that this can be done. std::num::pow() is a good example, I think.
Suppose I already have a program which is using std::num::pow() with a
self
I disagree with that: I never accept compromises, this is
the way how to develop magnificient software
Because it's not. Unless you use magnificient only in academic context.
? I'm not doing academic things.
It's not so much about wether or not overloading could be used in rust
without
On Fri, Jul 25, 2014 at 10:34 AM, Patrick Walton pcwal...@mozilla.com
wrote:
On 7/25/14 10:10 AM, Josh Haberman wrote:
On Fri, Jul 25, 2014 at 10:04 AM, Patrick Walton pcwal...@mozilla.com
wrote:
Neither auto-ref or ad-hoc operator overloading
would let you write a generic function that
On 7/25/14 3:20 PM, Josh Haberman wrote:
Got it. So the ad hoc part refers to having a template parameter, but
not being able to check its capabilities/interface at template
parsing/typechecking time, it sounds like?
Right. (The term comes from Making Ad-Hoc Polymorphism Less Ad-Hoc,
which is
On 7/25/14 8:26 PM, Patrick Walton wrote:
Uniform value representations work well too (as
OCaml shows), but of course you'll pay a performance cost for that.
Oh, note that Greg's notes are a little bit out of date when discussing
the performance tradeoffs of uniform value representation. On
23 matches
Mail list logo
