[luddy]

Yes, mutation of containers is definitely a problem. The natural semantics in SSA is something like container' = F(container, key, value). But of course this functional semantics straightaway diverges from the physical realization we expect as programmers, namely not a new thing called container', but the original container whose state has changed.

SSA is terribly overworked. It was a great formulation for certain compiler problems. To my mind, the problem for which it was perfectly suited was value numbering. Doing it in SSA form made it not only fast, but gave it a deeper power, as it became possible to easily "reach back" to deeper levels of input to an expression. But for a reason that's unclear to me, it was pushed into all kinds of applications where it's much less obvious that it's a good choice. Treating it as a programming language (lol) is, I guess, kind of the limit of wishful thinking about its universality.

[chubot]

Hm that is an interesting viewpoint. It seems like compilers are converging on it though? LLVM and GCC both use it.

I recall this talk being good:

GopherCon 2017: Keith Randall - Generating Better Machine Code with SSA

https://www.youtube.com/watch?v=uTMvKVma5ms&t=1s

Go has built-in mutable containers, and no const, yet they still use SSA. Is there a real alternative?

I guess it is mainly for speeding up code that uses a lot of integers and doubles and so forth, and not code that uses a lot of strings and containers?

[luddy]

>> Go has built-in mutable containers, and no const, yet they still use SSA.

Right, as you say, compilers are converging on SSA, and almost all languages have mutable containers. All it means is that there's a mismatch between the semantics of the IL and the semantics of the language. That's a fairly common situation; there are lots of semantics (like concurrency and associated memory consistency) that can't be captured in an IL as they occur in reality, in the language being compiled. It's just a thing that has to be worked around.