Hi. Wow. I can hardly believe my eyes. You’re building yet another backend.
The memory-ownership argument makes sense to me: a tracing GC does rule out precise Perceus-style ownership, and that’s a real limit rather than a design mistake on your part.
What I don’t follow is why that points at Rust. If the plan is unsafe code with a custom PerceusBox bypassing the borrow checker, then lifetimes, ownership and the aliasing discipline are all switched off, and what’s left is LLVM with Rust syntax on top. Koka, which is the reference implementation of the technique you’re after, targets C. purec already exists here and could use some love perhaps. So what does Rust give you once the checker is out of the picture that C or Zig or direct LLVM IR wouldn’t?
The part that worries me is that Rust’s unsafe is stricter than C rather than looser. &mut emits noalias, and provenance and Stacked Borrows make aliasing patterns that are fine in C into UB that LLVM is entitled to miscompile. A refcounted aliased object graph is close to the worst case for that. If you go this route I’d want to know the soundness plan early: is the whole thing running under Miri in CI, and what are the documented invariants on PerceusBox? That’s the sort of thing that’s very hard to retrofit.
Separately, and this is the thing I’d most like to see regardless of which backend wins: tcorefn is still local on your machine and it’s now a dependency of three projects. It’s the most reusable thing you’ve built and the only piece that survives a pivot. Even a rough patch and a format sketch in a public repo would let other people build on it and would make both backends reproducible.
And a straight question, no judgement in it: is the gopurs release still happening? You mentioned cleanup, Aff and an official release yesterday, and I’d like to know whether to treat gopurs as something to plan around or as a finished experiment.
(
