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 64
On 7/25/14 8:10 PM, Lionel Parreaux wrote:
Oh I'm sorry I completely missed your message, because I was not
subscribed to the list.
Thanks for the explanation. I do realize that this is the tough part,
compared to a system like Haskell where everything is boxed.
It's interesting to hear that th
Oh I'm sorry I completely missed your message, because I was not subscribed
to the list.
Thanks for the explanation. I do realize that this is the tough part,
compared to a system like Haskell where everything is boxed.
It's interesting to hear that this is how it was (meant to be) done in a
prev
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
On Fri, Jul 25, 2014 at 10:34 AM, Patrick Walton
wrote:
> On 7/25/14 10:10 AM, Josh Haberman wrote:
>
>> On Fri, Jul 25, 2014 at 10:04 AM, Patrick Walton
>> wrote:
>>
>>> Neither auto-ref or ad-hoc operator overloading
>>> would let you write a generic function that calls
>>> `pow` and works opt
> 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
> w
On Fri, Jul 25, 2014 at 1:45 PM, Gregor Cramer 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 defined
> 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
> 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
On Fri, Jul 25, 2014 at 3:36 PM, Gregor Cramer 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 of the languag
> > 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
> 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 pow(base: T, exp: uint) -> T { base.pow(exp) }
>
> trait HasPow {
> fn pow(self: Self, exp: uint) -> Self
> }
>
> Or, just use HasPow in y
On 7/25/14 10:10 AM, Josh Haberman wrote:
On Fri, Jul 25, 2014 at 10:04 AM, Patrick Walton 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
som
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 pow(base: T, exp: uint) -> T { base.pow(exp) }
trait HasPow {
fn pow(self: Self, exp: uint) -> Self
}
Or
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 pow(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 is this
On Fri, Jul 25, 2014 at 10:04 AM, Patrick Walton 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++ ad-hoc templates, w
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 t
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 this
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 pow>(mut base: T, mut exp: uint) -> T; //
uses the exponential trick
pub fn pow(mut base: i64, mut exp: uint) -> i64; // uses some
cool
> 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 of reasonab
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 wrote:
> Hi Marijn,
>
>
>
> > Firstly, blanket statements like "This makes generic programming
>
> > impossible" and "it does not allo
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 overw
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
Hello Gregor,
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.
Traits provide a more well-defined, easier to reason about alternative
to overloading. Th
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 PowImpl
{
fn pow(self, exp: uint) -> Res;
}
fn pow>(t: T,
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
26 matches
Mail list logo