Haha. Yeah, I feel that way especially right after I post something and re-read it. Because then it’s no longer a secret.
Yes, that’s true. But if you change the type of A, a compile error would be helpful and may occur more often if you’re not relying on a typeclass/trait that is used so pervasively. I think it’s a matter of degree, not 0 and 1.
What they’re saying here,
It is useful for the sake of future maintenance to stick with monomorphic functions where possible. (You can make a function monomorphic with explicit type annotations or type applications.)
is that you have a choice when you write the original code (before refactoring). You can call a polymorphic
length method or a monomorphic one (at least in Rust and Haskell, you have that option). If you don’t have a specific need for polymorphism, then why not use the monomorphic
length so the compiler is more likely to help you later during refactoring.
I do think the example is contrived in the Rust case, however, because I would never have used
.iter().count() to get the length of a Vec. Iterators are normally only used to calculate summary info when it isn’t immediately available via some other function.
The example showing the use of polymorphic Haskell length function is more realistic. I would definitely have used the polymorphic
length in that case.
Very true. It may just be Haskell’s typeclasses that are a little overboard. Rust’s traits do seem very well designed, and I know a huge amount of effort was put into that.
Yet this brings up another possible downside to adding ad-hoc polymorphism – the OCaml team and the community would need to spend a very large effort designing the shared typeclasses/traits (or whatever mechanism used), and also redesigning the standard library and alternate standard libraries to work smoothly and safely with them. Is that realistic? It’s something to at least keep in mind, right?
I don’t follow you. In the example it is the core data structures (Iterator in the case of Rust) that are using polymorphism. The example code (what you’re calling business logic) is just calling their
True, and maybe it isn’t a huge problem. Their assertion is only that “Ad-hoc polymorphism erodes type-safety”, they doesn’t say how much. How much is pretty hard to say, since it depends on lots of factors. One of them is how carefully the traits were designed and applied, as you say.
Absolutely! There are significant upsides to ad-hoc polymorphism. I posted that article because I think it’s also important to consider downsides.
My real fear is that OCaml would become more complex to read and write. OCaml is the only language I’ve found that has good runtime performance and behavior, but is also very straightforward to use. I hope that OCaml doesn’t go down the ad-hoc polymorphism path without a thorough and vetted design, including how it will be applied in the standard library, as well as to primitive types, etc.