[rust-dev] Implementation of traits in Rust: could it be dynamic?

Lionel Parreaux lionel.parreaux at gmail.com
Thu Jul 24 08:59:41 PDT 2014


Hi,

Could you provide a link to Patrick's description of size/alignment-passing
implementation? I'm interested in these things.

Well, there could be a warning if the compiler switches to such an
implementation. It's arguably still better than not compiling at all.
However, I don't have enough experience with type classes to know whether
such situations actually happen in the real world. But didn't Nawfel BGH
give an example of that?

I'm not an expert in embedded systems, but I know that in some embedded
systems, especially when memory is scarce or when the instruction cache is
small, code size does matter more than the number of instructions executed
per function call. It would probably be useful to be able to use generic
libraries but still tweak the amount of monomoprhization in order to
control the size of the generated executable.
I don't know if this is the case for Rust, but executable size is an
endemic problem in C++ because of wild template instantiation.

I can't pronounce myself about the suitability of features in the Rust
language, but it may be worth noting that some convenient high-level
features are already present in the language, like garbage collection.
Also, even C compilers output code with dramatically varying efficiency
depending on the chosen levels of optimization -- and sometimes small
details can disable optimization opportunities.

Cheers,
LP.



2014-07-23 4:13 GMT+02:00 Cameron Zwarich <zwarich at mozilla.com>:

> 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.parreaux at 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 at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140724/63272a2d/attachment.html>


More information about the Rust-dev mailing list