[tines]

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]

"Does type X have an implementation for typeclass Y" isn't always easy to answer.

https://aphyr.com/posts/342-typing-the-technical-interview

[tines]

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]

That typeclass resolution can encode some heavy computation, the example being n-queens in the article.

[tines]

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.