Scope introspection builtins #492
Comments
Let's say you have namespaces |
@krader1961 There is no "nested namespace". The module |
Yeah, I see that now that I've read the docs more carefully after my previous question. The problem is that most people are going to look at namespaces |
Names like `$a🅱️ c:d` are resolved as if it is `$a:[b:][c:][d]`. This also changes the resolution of variable names ending in :, so that they can be used to refer to namespace variables. Since namespace variables are now accessible and can be accessed like maps, this addresses #492.
A different API has been implemented: namespaces can now be indexed like maps, and |
In my tests,
|
It would be nice if we have a pair of builtins for examining (lexical) scopes.
Scopes have two parts: a
names
part, storing variable names, and auses
part, storing other namespaces used in that scope:elvish/eval/scope.go
Lines 3 to 7 in 2d837f1
Hence it makes sense to have two builtin functions for examining these two parts. One
list-names
and onelist-uses
.list-names
takes an optional namespace name and lists all names in that namespace. For instance,list-names builtin
lists all names in the builtin namespace, andlist-names local
lists all names in the local namespace. When no namespace or""
is given, it should list all names in the local, up and builtin namespaces, akin to how variable name resolution workselvish/eval/eval.go
Lines 368 to 404 in 2d837f1
In short, "list-names ns" should list all such names n that $ns:n is a valid variable.
list-uses
does not take arguments, and always lists names of namespaces used in the local, up, or builtin scope. This is to mirror the behavior of namespace resolution, which always happens as described:elvish/eval/eval.go
Lines 406 to 417 in 2d837f1
The text was updated successfully, but these errors were encountered: