Even if we could do a size/alignment-passing implementation like Patrick describes, would be it even be appropriate? It wouldn’t make sense for a systems language to transparently switch to a dramatically less efficient implementation mechanism without the programmer’s involvement.
Is there any place where an unbounded number of dictionaries at runtime is actually appropriate for solving a real problem in Rust? Cameron On 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 W<T> { > f: T > } > > trait Show { > fn show(&self) -> int; > } > > impl Show for int { > fn show(&self) -> int { 666 } > } > impl<T:Show> Show for W<T> { > fn show(&self) -> int { self.f.show()+1 } > } > impl<T:Clone> Clone for W<T> { > fn clone(&self) -> W<T> { W{f:self.f.clone()} } > } > > fn foo<S: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
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
