> Scala's for/yield has surprising behaviour ... because it doesn't have a categorical grounding
Not sure what you're talking about, but for/yield is syntactic sugar for map/flatMap, just like the "do notation" is in Haskell. Of course it has theoretical grounding, because it wouldn't work without flatMap being the monadic bind.
> mixing lists and sets
Again, not entirely sure what you're talking about, but if true, it's entirely unrelated to for/yield.
I believe that he's referring to the fact that Scala's Set is not a monad, so it "shouldn't" have a .flatMap operation.
Scala has other containers that have a .flatMap operation that are not real monads, such as Future and Try.
That can lead to surprising behavior on for/yeld loops.
Disclaimer: I do work in Scala and enjoy the language.
I mean if you write something like:
(for {
x <- List(1, 1, 1)
y <- Set(x)
z <- List(y, y)
} yield z).length
It's only surprising if you ascribe monadic properties to that syntax versus understanding it as literal syntactic sugar and absolutely nothing else.
I would say: it is `Set` and `List` that are wrong in that example, not `for`. That said, `for` really does have some issues (enter https://github.com/oleg-py/better-monadic-for/blob/master/RE...)
Nonsense. Scala was designed to make programming easier and safer than Java - XML literals and pattern matching certainly have nothing to do with category theory. Scala's for/yield has surprising behaviour when e.g. mixing lists and sets, precisely because it doesn't have a categorical grounding and was implemented in terms of what working programmers wanted to do with it rather than enforcing that you've formed a valid semigroupoid in the category of endofunctors.
Over time it's emerged that some categorical constructs provide useful ways of thinking about code and solving programming problems, but you're putting the cart before the horse if you think the language was designed for category theory.