OK. So I've looked at Rust, and it appears to me that it has exactly the problem that killed BitC: instance resolution ambiguity.
Nicholas does a good job of stating his goals here<http://smallcultfollowing.com/babysteps/blog/2012/10/04/refining-traits-slash-impls/>: coherence, link safety, overloading, and termination. The problem I am seeing is that Rust trait implementations are exactly like Haskell type class instances and suffer the same coherency issues. As with Haskell, Rust requires that a given Trait has at most one implementation for a type T. Also like Haskell, impls do not appear to be lexically scoped, with the consequence that (a) generic trait implementations complemented by specialized implementations aren't resolvable and (b) the "only one implementation" rule can only be checked on a "whole Crate" basis. Except it appears to me that this isn't possible, because a Trait requirement can appear at an interface, with the result that two crates interacting through an interface can have independent implementations of some trait for the same type. Am I failing to understand something here?
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
