3 ms·

Is it that Haskell, at least, doesn't support overloading in the same way as Swift? I don't know either of them well enough to be sure. It seems like there's a

by tines 2y ago

Is it that Haskell, at least, doesn't support overloading in the same way as Swift? I don't know either of them well enough to be sure. It seems like there's a combinatorial explosion of possible overloads in Swift, whereas if you implement a function with the same ergonomics in Haskell (e.g. a printf-like function), the only thing the compiler has to do is ask "Does type X have an implementation for typeclass Show? Yes? Done." Essentially Haskell solved this overload inference problem in the same way that iterators solve the M*N problem for basic algorithms: convert all these disparate types to a single type, and run your algorithm on that.

ackfoobar 2y ago
"Does type X have an implementation for typeclass Y" isn't always easy to answer. https://aphyr.com/posts/342-typing-the-technical-interview https://aphyr.com/posts/342-typing-the-technical-interview
- tines 2y ago
  That post, while awesome (as is the rest of aphyr's stuff), is a lot to wade through to get to the point you're trying to convey. Can you spell it out for me?
  - ackfoobar 2y ago
    That typeclass resolution can encode some heavy computation, the example being n-queens in the article.
    - tines 2y ago
      That's only the case when you turn on the "enable arbitrary computation in typeclasses" flag, so I'd say it's not much of a worry.