Hi David, > What would you do with multiple instance declarations that differ by > specificity? For example, one declared on [int] and one declared on [T].
Eventually, we'll have to specify a scoring scheme. The closest import always wins, so you can disambiguate explicitly. If you have multiple interface implementations imported at the same level, I'd make that an error in the first version of this system, but I agree that eventually we'll want specificity rules. > This comes down to the different implementation approaches polymorphism. > Monomorphizing is rare in the ML/Haskell tradition, so type classes with > dictionary-passing is a nice fit. But it's not as clear what happens to type > classes when you introduce specialization. Monomorphizing generics that take interfaces sounds wrong. It is probably a win in some situations, and heuristics can be found to detect such situations, but I doubt we'll want to do in general. (What happens seems quite clear though -- you compile a version of the function with the vtable known at compile-time, so all dispatch becomes static.) > Overloaded arithmetic is definitely a pleasant aspect of Haskell's type > classes. But they do exploit type inference pretty heavily. For example, > literals have polymorphic types, and expressions can be given different types > based on the expected type of their context. Have you thought about how this > would look in our system, where inference is more limited? If we stick to our current approach (literals have unambiguous types, binops always act on values of the same type), the only new subtlety is that the type checker has to figure out the return type of a method. I think this can be done early enough, but I'm not deeply familiar with our type checker, so I'd have to try and see. > For example, how do we prevent programmers from declaring some things to be > instances of `send` that aren't supposed to be? For `copy`, this is easy -- your `copy` method does a copy, and the compiler has the full type of the arguments when compiling the method body, so it checks, and complains when you implement a copy method on an invalid type. We'll have to introduce some explicit way of checking whether a type is sendable to do the same for `send`. We'll probably have to wire in automatic 'derived' instances/categories for this to be pleasant though, or you'll be forced to implement your own instances for every tag you declare. Or maybe `copy` and `send` will just look and behave like interfaces on the surface, and in fact refer to some built-in magic interface that the compiler handles specially. > And IINM, there are still blockers that are well-established and fundamental, > like stack growth and x64, no? Right, but those have very competent people working on them already (and are progressing really well). Actually, I agree that this isn't something that has any bearing on a first release. Coming up with new neat requirements at the last moment is a sure way to make that release be delayed. But at least having a proposal to point people to when they ask about support for dynamic dispatch would be a plus. (And yes, this will end up on the wiki, but I find that initial discussion is better done in the mailing list.) _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
