what rayfall takes from k, and what it does not
summary: a year in. writing down which of k's choices made it into rayfall and which i deliberately left behind.
Core idea: Rayfall keeps K's runtime commitments while choosing a more explicit Lisp surface for users who should not have to learn K notation to use the database.
K is right about the runtime. Rayfall is right about the surface for the people I am writing it for. Both can be true.
The runtime in Rayfall is K's: arity-classed primitives, vector-first evaluation with no scalar code path, every value a typed column. Those are not surface choices; those are the bet about what makes a vector language fast and what gives the optimiser something to work with. I would not want to be the person who tries to talk me out of any of them.
The surface is not K's. Rayfall is a Lisp - (+ a b), not a+b; (reduce +), not +/; (set x ...), not implicit assignment by adjacency. The audience for a database I want people to actually use cannot be limited to the small group already fluent in K notation. The cost of the verbosity is one parenthesis pair per call site. The benefit is that every reader of every line knows what is happening on first read, including the author returning to the code later.
Both can be true. I no longer treat either side as a compromise.