Joseph Ferano
84e170b349
A sequence library normally returns new sequences. There is no allocator, so every one of these mutates the storage it was handed and a slice is the handle that makes that useful: (slice grid 4 9) is ptr+len into grid, so sorting it sorts those five elements and leaves the rest of grid alone. The test asserts exactly that — it sorts a subslice and prints the whole owning array — because it is the property that would die silently the day a slice parameter started being copied rather than passed by value, and -O2's mem2reg would hide it. Insertion sort rather than anything faster. Quicksort wants a stack and mergesort wants a buffer, and neither exists; insertion sort needs a swap and two indices. It is also the only one of the three whose inner loop is short enough to read, which matters more than the asymptotics on the slice sizes a frame loop actually sorts. The `and` guarding it short-circuits, and that is load-bearing: at j = 0 the left test fails and (at s -1) is never evaluated, so the bounds check never fires. Over [i32] and nothing else. There are no generics, so a second element type is a second copy of all seven functions emitted into every program that links the prelude, and i32 is the type indices, ids and tile values already have. An f32 set waits for a program that wants one. min-i32 and max-i32 return (Option i32) rather than a sentinel because there is no i32 that means "the slice was empty" and is not also a possible element. sum-i32 accumulates in i64 and widens each element explicitly — there is no implicit widening anywhere, and an i32 total over a screenful of i32 is how a sum wraps without anyone noticing.
