The feature in OxCaml that more languages should steal
46 points by vaguelytagged
46 points by vaguelytagged
A commenter on Hacker News shared that Swift has a similar @_noAllocation annotation. It's behind an experimental flag. This also led me to notice that Clang has a nonallocating attribute which also behaves similarly, you need to set -Wfunction-effects to get warnings. I've edited the article with this info.
At best, in Zig (...) you might be able to minimize regression through convention by not passing an allocator to a function. But convention can be ignored.
Is this correct? I thought the whole point of passing allocators as function arguments was so that functions CANNOT allocate on the heap unless it is passed an allocator as one of the arguments?
It's true, just a convention. You can conjure up an allocator inside a function the same way that you do outside of it.
Or stick an allocator in a global variable, or follow some pointers back to an allocator you stashed in some data-structure. It's a lot like go's Context, where you probably should be putting one on the heap but nothing will stop you from doing so.
D has had nogc for a while, which I think has similar semantics, because the GC is responsible for allocations.
https://dlang.org/phobos/dmd_nogc.html
It also added nogc exceptions at some point as an experiment (haven't checked the current status/implementation).
nogc does not prevent manual allocations, which is available right from the stdlib (core.memory), and TFA rejects “conventional” allocation avoidance.
Well the OxCaml program will also need allocation right? Besides [@zero_alloc] only prevents GC alloc AFAIK and has (like in D) ways to break its guarantees.
Well the OxCaml program will also need allocation right?
How is that relevant? This is about surfacing function effects.
Besides [@zero_alloc] only prevents GC alloc AFAIK
Does oxcaml have any other trivially reachable way to heap allocate? Because needing to go through FFI would be impossible to miss.
Because we've lost the ability to give articles descriptive titles, it's the ability to annotate a function with [@zero_alloc] and have the compiler refuse the program the function's call tree touches the heap.
wonder if it would be possible to have something that works for lots of different predicates like this. "doesn't throw or panic", "is lock-free" and "always terminates"?
It’s called an effect system.
No? I haven't heard of an effect system that tracks things like this code "does/doesn't allocate". I've seen plenty that track things like "this code does/doesn't do network IO".
No? I haven't heard of an effect system that tracks things like this code "does/doesn't allocate".
That... doesn't really matter? Even if there is no existing existing effect system which does it, allocations are pretty obviously something an effect system can cover, it's "just" a question of deciding that allocations are an interesting effect rather than "pure computation". In the same way most languages making allocations transparent / invisible doesn't prevent zig from treating allocators as an injectable dependency.
Okay, thanks. I've just never seen one implemented in anything other than a functional language that treats allocation as free and invisible.
Koka definitely has effects related to allocation, though I’m not sure that the semantics in the language would allow this sort of control as it currently exists. Unobservable allocation effects seem to get erased. https://koka-lang.github.io/koka/doc/book.html#sec-runst
Koka’s effect system does this: https://koka-lang.github.io/koka/doc/book.html#sec-effect-types.
Scroll down to “3.2.5. Reference Cells and Isolated state.”
Another way to avoid allocations is to only use core in rust.
"avoiding allocations" is only part of the story. Your point amounts to "control your dependencies" or "check the whole call graph manually".
The post's focus is how the tooling (here, a compiler) enables static enforcement of a property, as well as a productive workflow for identifying places where said property is violated.
D has @nogc and then it's a matter of only using abstractions you control with clear allocation patterns.
I find this feature pretty interesting as it touches at the border of how I see functional languages now. Basically a pure functional language is a language that should not touch the heap or at least should govern the heap in the sense that anything allocated on the heap should be cleaned with the stack itself. This is for instance the purpose of unique_ptr<..> in C++, for instance.
This is a feature that is primarily relevant for GC languages. Zeroalloc means that you don’t trigger high latency GC. With memory management techniques that don’t have high latency tails you probably get less value out of such a feature.
I don't think it's usefulness is limited to GC languages. Indeed Clang now has this. Everyone is starting to want the compiler to provide assurance that some areas don't allocate. Other groups to date were just accomplishing this through convention.
But certainly it might provide significant clarity in a language like Go where so much escapes the stack...