On 1/9/12 5:36 PM, Tim Chevalier wrote:
The problem the paper addresses is in Haskell, where having multiple
instances in scope for the same class and type can cause unpredictable
behavior. (The paper explains the basic problem in more detail pretty
well.) It seems like there's an analogous issue in Rust when you
import multiple sets of methods for the same type class, which I
understand is handled with a compile failure. A difference is that
with instance chains, an instance is not a "first-class" thing that
you can import (like an item in Rust terminology) -- rather, you use
type-level if-then expressions to disambiguate which instances apply.

Skimming the paper, I don't see where the modularity problem is addressed (e.g. one module defines an instance of Show int, another module defines an instance of Show int, now the two cannot be linked). It only solves the problem in the overlapping case, in which both typeclass instances apply, but one is more specific than the other (e.g. Show [int] and Show ['a]). My initial reaction is that Rust-style named instances are the simpler solution. We make the programmer decide explicitly which implementation to use; we never try to guess.

Patrick
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to