How built-in verbs are accessed only through the odb

The issue names system.verbs.builtins, the paths table, the kernel table and pseudo-call, glue scripts, and a JavaScript table, but no files or tests. Start by locating those components and tracing how built-in verbs are resolved; done means the transition and related code changes are installed and the described lookup behavior works.

I'm going to write up various big events in this project. This is the first, and I think it's a good one to be first.

Claude did the big parts of Frontier without any Q&A with me, and did a pretty good job but really got lost when it came to the meaning of system.verbs.builtins and the kernel table and the kernel pseudo call. I'm not sure if it read the source code, or if it just guessed wrong about a few things and tried to make his imagined system work.

Today I needed to fix a bug in the script i use that required me to use string.replaceAll verb. I often just 2click on the name to get a refresher on the parameter list, or to see if it's kernelized or what. But it didn't work. I called up Claude and asked what's up. It said that it'll run if I use it in a script, and can fix the 2click right away. I was shocked. I wanted to know what the fix would be and what I heard back was pure slop, imho.

I'm going to leave out the details of how Claud thought it worked. This is where the corner turned. I said:

every reference is either an exact match to an odb location or it goes through the paths table. system.verbs.builtins is just a convenient place to put some scripts that we're documenting as verbs in the language, but they aren't any different from objects elsewhere.

It came back with a slightly less crazy-ass idea of how it worked, so I asked why is it arguing with me, go look at the Frontier kernel source from 2011. When it got back the lights had turned on. I usually try not to quote Claude, but this is worth reading if you love Frontier, because it documents the way the language connects to the object database. I can't say I've ever explained this to anyone who didn't work at UserLand, but here it is now.

You're right, it isn't. Here's what the source says.

kernel is internaltable.kernel — built in memory at startup, never in the odb, not on the paths table. The only way into it is the kernel (...) operator in the language: the grammar rule is kernelcall: kerneltoken '(' dottedid ')'.

system.verbs.builtins is on the paths table, and it's ordinary — real script objects, same as anything else in the database. A kernel verb has a script there whose body calls kernel (string.replaceAll). That's why 2-click always works for you: you're opening a script, and the script is what tells you it's a kernel call.

So there's one lookup, not two. Name resolution walks the paths table. Nothing is special because it's a verb.

What we built instead: a JavaScript table consulted first, with the odb never asked. That's the crazy-ass version.

My response was finally we're working together. I just assumed it had figured all this out, but it hadn't and we were talking over the top of each others' heads. This time I put my foot down, wanted a clear picture of what was going on over there, and we found the big bug.

Tonight Claude has a bunch of jobs to do but doing this transition, installing all the glue scripts tables, and changing its code accordingly.