On 12-10-11 07:26 AM, Bennie Kloosteman wrote:
1.Specifically the Instance Coherence problem
Yes, over the course of the spring and summer we moved Rust towards a set of instance-coherence rules specifically chosen to balance difficulties BitC encountered (and that Haskell and other languages have themselves confronted and chosen ad-hoc rules to solve). It's a balancing act but we think we have a good set of rules here. We had an _ok_ set of rules before, too, but the ones we moved to this summer seem to be working out even better. For some background, see Patrick's blog:
http://pcwalton.github.com/blog/2012/05/28/coherence/
2.*The type class notion (more precisely: qualified types) is seductive, but absent a reasonable approach for instance coherence and lexical resolution it provides an unsatisfactory basis for operator overloading. There is a disturbingly close relationship between type class instances and object instances that needs further exploration by the PL community. The important distinction may be pragmatic rather than conceptual: type class instances are compile-time constants while object instances are run-time values. This has no major consequences for typing, but it leads to significant differences w.r.t. naming, binding, and [human] conceptualization.*
As we've stated, Rust traits are both available as compile-time an runtime entities, from the same definition. This is a trick that Marijn stumbled onto last year. If you treat a trait name as a type and cast a pointer to a runtime value implementing that trait to a pointer to the trait type, you are given a vtable-pointer on which to perform dynamic dispatch to the implementation. Alternatively, if you use the trait name as a static type bound in a polymorphic function, the function is statically specialized to the implementation type at the call site, and there's no runtime cost. This all seems to work very well in practice.
I'm not sure what all the rest of the ominous language in this paragraph refers to; in general I'd appreciate if you could try to ask specific questions or pose specific suggestions. Much of this thread is too vague to either answer or take any action on, thus nonproductive.
3.And the VT Table ( which needs a this pointer)
Only when you are doing dynamic dispatch. Most uses of traits appear to be as static type bounds, which wind up statically dispatching (and specializing, inlining).
And introducing SelfType was an even bigger issue than introducing subtypes. It means moving out of System F<: entirely, and into the object type system of Cardelli *et al*.
Rust's use of 'self' is much, much more conservative than a Cardelli-Abadi object calculus. It does not support any such subtyping relationship on the 'self' type as those calculi are striving for. In Rust, 'self' is only ever treated as the opaque pointer+vtable pair to a specific trait (without subtyping) or as a syntactic placeholder which is replaced by an _exact_ implementation type (again without subtyping) when instantiating a trait. Neither of these contexts demand Cardelli-Abadi self-types.
*Instance Coherence and Operator Overloading*
This is just a restatement of the instance-coherence problem, with a further vague implication that if you want very rich forms of overloading, it is slightly more pervasive a problem. Rust is quite conservative on operator overloading, and it doesn't seem to be any worse than any other context of instance coherence enforcement.
(Please note that even in that section, he shows that haskell and C++ are both quite able to accommodate these issues by adopting certain compromises, they don't fundamentally fail as languages due to the tradeoffs they adopt. We have done the same. Shipping a language that works is more important to us than making one that can do everything.)
*Conclusion about Type Classes and Overloading*:
This paragraph is the one you pasted in above under '2.* the type class notion'; I responded up there.
-Graydon _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
