> Phil Wadler, the first author of the paper you cite, was literally a principal designer of Haskell.
Yes, I know that. That's the point.
> SML does not have type classes; your quote points out a deficiency in SML that motivates type classes.
Again, that's the point. It's what "have an influence" means in that it was SML that influenced or inspired Haskell's type classes. And it's part of my overall point of SML being rather influential, although quietly.
> Traits in Rust are much more closely related to Haskell's type classes than to traits in the OOP sense.
I'm not so sure about that from what I have read. But I don't have enough information other than to just point to things I have read.
While I can't find any concrete information, I would be quite surprised if Rust's traits were influenced by type classes rather than the more OOP interpretation of traits (in the design space of traits vs mixins vs interfaces).
You asked for an example of Haskell influencing languages other than Idris. Type classes are a pretty clear example. I don't see how it is particularly relevant to this that they were motivated by a deficiency in SML.
I'm not familiar with the origin of traits/mixins in the OOP world, but my understanding is that they generally contain implementations of methods; they are a "part of" a class. Type classes and Rust traits, however, are more like interfaces. I'm pretty confident you won't find any notion of trait that predates type classes and can define what a Functor or Monad is. My reading of the SO answer you link is that Rust traits started off similar to type classes and have grown closer and closer over time. I'm not sure what a clearer indication of Haskell's influence would look like!
> Another unusual feature is that methods do not "belong" to classes; classes do not provide a namespace for generic functions or methods. Methods are defined separately from classes, and they have no special access (e.g. "this", "self", or "protected") to class slots.
Of course, the whole idea of having methods as separate entities might sound a bit "alien" today. Still, the idea of traits as abstract contracts, with separate and potentially multiple distinct implementations, comes directly from this, IMHO.
Yes, I know that. That's the point.
> SML does not have type classes; your quote points out a deficiency in SML that motivates type classes.
Again, that's the point. It's what "have an influence" means in that it was SML that influenced or inspired Haskell's type classes. And it's part of my overall point of SML being rather influential, although quietly.
> Traits in Rust are much more closely related to Haskell's type classes than to traits in the OOP sense.
I'm not so sure about that from what I have read. But I don't have enough information other than to just point to things I have read.
https://stackoverflow.com/questions/28123453/what-is-the-dif...
While I can't find any concrete information, I would be quite surprised if Rust's traits were influenced by type classes rather than the more OOP interpretation of traits (in the design space of traits vs mixins vs interfaces).
https://doc.rust-lang.org/book/ch17-01-what-is-oo.html