Scope all commands to current namespace (no global fallbacks for names or PPE)

[ChrisPenner]

Overview

Current trunk often falls back to a Global name search in a lot of commands. This was fine early in the life of UCM because loose-code was generally small-ish, but now that it contains names for every project AND copies of all the transitive dependencies of each project for every branch it's not so small anymore 😬

As a result, a lot of commands are unnecessarily slow because they load the global names object when they don't really need to.

As an experiment, we'd like to see how it feels to remove the global names fallback for all commands except view.global, names.global, and namespace.dependencies. view and display will use the global names if provided an absolute argument.
If folks are game to try it out, play around with this branch and see how it feels.

This branch ONLY has names in scope for your current namespace, so generally cd'ing into subnamespaces of your project is not recommended, stay at the root of your project when you can. We're looking into ways of possibly improving this situation.

We also hope this can help users to recognize when they're missing names within their project. Previously these names might automatically resolve to some other name from some other project using the global fallback, but if they publish it then Share won't have those names and neither will anyone who pulls it.

Let me know if you have any questions, expect some speed-up to a few of your favourite commands as a result (e.g. display is now much faster)

Remember that UCM still often hangs on the first command until the whole codebase is loaded, so when testing performance of a command, run an ls first and wait for that to complete so you know the codebase is loaded before you test your command 🙂

Implementation notes

Known additional behavioural changes:

• find still falls back on a lib search if it gets no hits, but now it ONLY searches lib in the second search, because we know we already searched non-lib.
• Altered display to match view's behaviour for absolute args, i.e. it will load the global names object for any args which are absolutely qualified.
• Updated a bunch of transcripts to avoid ##Nat builtin hashes where possible, but some of them were too hairy to do that, so some transcripts have builtin-hashes now 🤷🏼‍♂️

Interesting/controversial decisions

Include anything that you thought twice about, debated, chose arbitrarily, etc.
What could have been done differently, but wasn't? And why?

Test coverage

Have you included tests (which could be a transcript) for this change, or is it somehow covered by existing tests?

Would you recommend improving the test coverage (either as part of this PR or as a separate issue) or do you think it’s adequate?

If you only tested by hand, because that's all that's practical to do for this change, mention that.

Loose ends

Now that we only have a couple combinators it's WAY easier to get the benefits of caching these things, and should do that soon :)

We can also probably get away with delaying loading the root branch by leveraging getCurrentBranch to load sub-branches rather than the whole thing until it's absolutely necessary (e.g. the user calls update). Should make UCM much more responsive.

• delete should check for endangerment from the project root, not the global root

[ceedubs]

What does this mean for calling ucm run myloosecode.main (not within an interactive UCM session)? I don't think that there is currently a syntax for doing this within the scope of a project. Would this use a PPE for the root namespace, or would it not have access to any names? The answer may be that we want to add syntax for doing this scopes within a project and that we don't care about doing it as loose code; I don't know.

[ChrisPenner]

What does this mean for calling ucm run myloosecode.main (not within an interactive UCM session)? I don't think that there is currently a syntax for doing this within the scope of a project. Would this use a PPE for the root namespace, or would it not have access to any names? The answer may be that we want to add syntax for doing this scopes within a project and that we don't care about doing it as loose code; I don't know.

Great question, AFAICT it appears to run code from the root, so I'd guess it's all in scope, but I'm really not sure how the runtime looks up names and in which situations. If it is loading all names, does it do it on startup? If so, maybe we can speed up the run command by deferring it or limiting the scope 🤔

Maybe @dolio has more info here?

[dolio]

The runtime doesn't care or know anything about names. It just gets fed code that works in terms of hashes (and not even UCM hashes at this point). So any name loading is happening before the runtime gets involved. Even for decompiling and such, what I've written just uses some provided pretty printing environment, and I don't think there is any control of what gets loaded on the consumer end of that.

[ChrisPenner]

This was a bit weird, I don't think the behaviour on trunk is consistent with this, but also don't think we really care since the frontend shouldn't be asking for things that are out of scope (and if it does, I guess it's fine if it renders with hashes 🤷🏼 ). I'm just going to delete this particular test since I don't think it makes sense, and I'm the one who added it in the first place 🙃

This doesn't affect Share since that uses a completely different api implementation.