dxo (Jul 17 2023 at 22:11): dxo (Jul 17 2023 at 22:11):I'm curious if people here have opinions on the recent fully in-place functional programming paper? https://www.microsoft.com/en-us/research/uploads/prod/2023/05/fbip.pdf
tldr of the paper is that there is a typechecker pass implemented in the koka language that can statically determine if a given function can be executed fully in-place (i.e. no allocations or deallocations, bounded stack space). Is this something that might make sense for roc? It seems quite complimentary to the language goals?
Folkert de Vries (Jul 18 2023 at 08:36):we're certainly very interested in this line of papers and have had direct contact with various authors. We are now actually mostly compatible with this most-recent paper in terms of how reuse is inferred and when reference count in/decrement are performed.
What we don't have is explicit borrow annotations (which we'd rather not add; we don't want users to have to deal with that, whether borrowing is advantageous is hard to tell and may change with trivial refactorings), and we don't have the inference that a function is in-place
Folkert de Vries (Jul 18 2023 at 08:37):I think it is a problem that the effect of these optimizations is hard to verify, so the compiler being able to tell you more (and perhaps the user asserting that a certain property should hold) seems very valuable
Folkert de Vries (Jul 18 2023 at 08:37):but it's not clear yet how we can unify those ideas with the other goals of the language
dxo (Jul 18 2023 at 10:55):yeah having the static guarantees seems very desirable
dxo (Jul 18 2023 at 10:57):although I think with the implementation in koka it’s still hard to tell whether things will actually be executed fip or not since it’s chosen by the runtime dynamically based on reference counts at the call site
dxo (Jul 18 2023 at 11:00):my intuition is that some kind of uniqueness / linearity notation at the call site might be desirable as well but I haven’t played around with it enough to tell for sure
dxo (Jul 18 2023 at 11:01):I also found it interesting that the fip solutions offered only a modest speed up over a more conventional functional approach with automatic reuse enabled, and that both were faster than the stl rb-tree with the standard allocator!
dxo (Jul 18 2023 at 11:07):could you expand more on the points re: borrowing? you’re just concerned about complexity and syntactic overhead? my understanding from the paper was that borrowing was not required in all cases (none of the sorts or tree insertions used it, only the traversals).
Folkert de Vries (Jul 18 2023 at 11:30):well we don't want borrowing to leak into userspace
Folkert de Vries (Jul 18 2023 at 11:30):but are happy to infer it, if there were a good method for doing so
dxo (Jul 18 2023 at 11:39):Folkert de Vries said:
well we don't want borrowing to leak into userspace
because of the extra cognitive overhead?
Last updated: Jun 16 2026 at 16:19 UTC