> I prefer to interpret that slide as saying that inventing them was > hard. We are in the comfortable position of having their work to build > on. Note that the far right of the graph says 'Hey, what's the big > deal?'.
Well, I stand by my concern. Type classes are still being studied, tweaked, and experimented with for Haskell, and they're a pretty subtle thing. They're a constraint language, and it's tough to make constraint languages provide clear solutions, clear performance models, and clear error messages. > I expect we're definitely going to keep requiring full type > specifications for top-level functions (and I think that's a very good > thing--though I may at some point argue that for inner functions they > should be optional). Doing Hindley-Milner type inference with required > top-level specifications removes the problem of overzealous > generalization. I think this would be a good road to take (though I > get the impression others on the team are less enthousiastic about > H-M). Is that much different from what we currently have? Ignoring inner functions for the moment (which don't even really exist yet, right?), aren't local variables (i.e., `auto') all that's left? FWIW, these are my reservations about H-M for Rust: - Decidability/tractability is delicate, and imposes constraints on the design space for the type system. - Inference in the presence of refinement types is a harder problem than inference for ML/Haskell. That said, this may have a known solution in the literature; I haven't looked. - Inference error messages are bad because when two disparate pieces of code disagree, the type checker can't generally tell who's right and who's wrong. - We don't mind requiring people to annotate top-level code anyway. - Inferring most general types lead to implicitly polymorphic code, incurring silent costs. - Global inference inhibits parallel compilation (not the most important point, I'll grant) Having said all that, what you've described sounds like it may address a number of these concerns. Particularly, local/bidirectional type inference can improve error messages and simplify the algorithm, and maybe that's closer to what you're describing. (In particular, I think it's generally possible to infer types for local functions using outside-in inference only.) Dave _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
