@zep playing around with `ud:take`, there seems to be a bug when using spans longer than 1: the last row will only have the first column populated.

repro:

function chunk(ud, x, y, w, h)
local s = ud:width()
local rows = userdata("i32", h)
h -= 1
rows:set(0, y*s+x)
rows:set(h, (y+h)*s+x)
return ud:take(rows:lerp(), nil, 0, 0, w)
end

function iota(n)
if (n > 0) return n, iota(n-1)
end

local data = vec(iota(8*8))
data:mutate("f64", 8, 8)
?pod(data)
?pod(chunk(data, 1, 2, 4, 3))

something that keeps happening when working on parens-8 is that I'll figure out a clever way to make my vm/compiler combo more effective, get really proud-snarky about it, and then find out later that it's something people already figured out a few decades ago.

the latest instance of that was the idea of using CPS at the compiler level instead of the vm level, which happens to be what "compiling with continuations" is about. I'm not sure how to feel about that. validation? frustration? I guess I wish I could work in that specific field of software full time instead of stumbling across this kind of thing in the dark.

working on the crescent (subset of lua) compiler for parens-8, I got so frustrated with string parsing that I started looking into writing an llvm backend as a joke, or so I thought.

turns out, v5's vm is similar enough to wasm that basing my hypothetical parens-8 llvm backend on wasm's is concerningly feasible.

parens-8 v5 is taking shape. working on it is a lot more fun than working on previous versions, partly because of the reduced constraints of the compiler code, mostly because the amount of bootstrapping required is a lot lower.

Soupster found a fantastic name for the quasi bytecode output of the v5 compiler: ps8 fir, for Parens-8 Fast Intermediate Representation.