>> In Haskell, and this is probably
>> worth following, only the module that defines the type, or the module
>> that defines the typeclass, can declare an instance for a
>> type/typeclass combo. So if your crate can 'uses' (as in, links) a
>> given typeclass and type, it also see any instance declarations for
>> them.
I'm pretty sure that's not right. See e.g. section 5.4 of the Haskell 98 report:
http://www.haskell.org/onlinereport/modules.html#sect5.4
I believe you can declare instances anywhere, and whenever you import from a
module with an instance declaration, you automatically import those instances.
I still have reservations about type classes, but I'm open in principle to the
idea. I'd personally want to see a pretty well thought-through proposal. When
SPJ says something is hard
(http://research.microsoft.com/en-us/um/people/simonpj/papers/haskell-retrospective/HaskellRetrospective.pdf,
slide 46), I believe him!
>> Then, as in your example, when a function passes an int to a function
>> one of whose type parameters is restricted to type Number, that is the
>> point where the vtable for int/Number is looked up, and passed along.
>> As an optimization, you can make this vtable point to the int type, so
>> that you don't have to pass both the vtable and the type descriptor to
>> the polymorphic function.
One of the design goals of Rust is to make the performance model as clear as
possible. Patrick has pointed out to me that right now, we have a pretty good
story for explaining the cost of polymorphic functions: every type parameter
corresponds to another argument that's passed into the function at runtime --
roughly, the vtable for the Rust's built-in system "type classes" (for memory
management and runtime type reflection). Now, extending this to arbitrary
vtables is reasonably consistent; bounded type parameters are still type
parameters, and they still take a vtable argument. But when you start talking
about optimizations that let you eliminate these arguments, I get nervous
because the cost model starts getting more complex.
But it would be a bigger problem if we tried to bring in full type inference.
Hindley-Milner is all about inferring the most general type. Having the
compiler decide to make our code unnecessarily polymorphic means making it
unnecessarily slow. :) But there aren't many languages with type classes, and
I've never heard of one without inference. I'm not sure what that would look
like.
Dave
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
