[Mathnerd314]

There is a way to do FBIP without reference counting - use immutable store semantics (always copy). At that point you are doing a lot of copying but Haskell etc. are actually pretty good at managing this sort of profligate duplication. And of course it is possible to use RC-at-compile-time and other analyses to optimize away the copying - the difference is that runtime RC is not required like it is in Koka. There is even a static analysis algorithm from 1985 https://dl.acm.org/doi/abs/10.1145/318593.318660 (never implemented in Haskell because they went with the ST monad) There is a theorem in the paper that for "natural" translations of imperative programs into FP, their algorithm will optimize the FP back to the imperative program or better.

[mrkeen]

> use immutable store semantics (always copy).

What does "always copy" mean? What and why would you copy?

[Mathnerd314]

Say you have an array x = [1,2,3]. You do x[2] = 4. Now you have two arrays, x_1 = [1,2,3] and x_2 = [1,2,4]. x_2 is a "copy" with all elements the same except one. The "always copy" here means that (semantically at least) every array modification creates a copy of the array like this. Naturally this is slow, if you implemented it as-is, but then there are the optimizations I mentioned. And it is much easier to optimize a simple semantics consistently than to debug a more complex one. It is somewhat similar to Swift's value semantics.