this remindes me of the issue i got when trying to implement finger
trees in Rust so long ago
https://github.com/rust-lang/rust/issues/8613
I suggested to let add a way to specify (in the code) how match
functions do we want to generate and failing at runtime when the limit
is reached. This made sense in my situation.
2014-07-22 18:23 UTC+01:00, Corey Richardson co...@octayn.net:
You can avoid monomorphization by using trait objects, which erase
the precise implementing type through a vtable + pointer.
http://doc.rust-lang.org/tutorial.html#trait-objects-and-dynamic-method-dispatch
has some documentation.
On Tue, Jul 22, 2014 at 10:16 AM, Lionel Parreaux
lionel.parre...@gmail.com wrote:
Hi,
So traits seem to be quite similar to Haskell's classes, being also used
for
parametric polymorphism. Now, Haskell classes are usually implemented
using
runtime dictionary passing. In general, code cannot be specialized for
every
function call, since there may be an unbounded number of instances
generated
for it, as is explained in this reddit answer:
http://www.reddit.com/r/haskell/comments/1ar642/what_type_of_binding_does_haskell_use/c94o2ju
Knowing that Rust implements traits using monomorphization of code (much
like C++ templates), I was curious about how it handled such cases, and
tried this:
struct WT {
f: T
}
trait Show {
fn show(self) - int;
}
impl Show for int {
fn show(self) - int { 666 }
}
implT:Show Show for WT {
fn show(self) - int { self.f.show()+1 }
}
implT:Clone Clone for WT {
fn clone(self) - WT { W{f:self.f.clone()} }
}
fn fooS:Show+Clone(s: S, n: int) {
let w = W{f:s.clone()};
if n 0 { foo(w, n-1); }
}
fn main() {
foo(W{f:42i},42);
}
It gave me an error: reached the recursion limit during
monomorphization,
which... well, that's a possible solution :)
I'm not sure whether this is a big problem in practice, but I was
wondering
if it would be possible to switch to some runtime mechanism in cases like
this. Maybe we could make a special version of every generic functions,
that
takes a dictionary at runtime and that would be able to handle types
unknown
at compile-time. We would switch to this version when monomorphization
does
not work. It could also allow dynamic linking of libraries with generic
functions, or it could be a way to compile some programs (or some parts
of
programs) much faster.
I was thinking about, for example, an IDE where generic function calls to
types defined inside the files currently being edited use their dynamic
version, so that recompile times can be virtually inexistent (like Java).
On
the other hand, the release build would of course monomorphize as much as
possible to make the perf optimal.
Now the question is: would this conform to the current semantic of
monomorphization? Do special things happen during monomorphization that
cannot be reproduced at runtime?
This is the case in C++ (and one of the reasons why C++ templates are so
bad). Is it the case in Rust, which should already have all the
required
info (type bounds) before monomorphization?
I apologize if this has already been discussed. I could not find many
satisfying answers by googling.
Cheers,
LP.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
