Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Supporting introspecting $E: as if it were a normal namespace #1026

Open
krader1961 opened this issue May 14, 2020 · 5 comments
Open

Supporting introspecting $E: as if it were a normal namespace #1026

krader1961 opened this issue May 14, 2020 · 5 comments

Comments

@krader1961
Copy link
Contributor

I was converting my fish functions for modifying my Anaconda virtual environment and was surprised to find I could not do keys $E: or has-key $E: MY-ENV-VAR. Is there some other way to iterate over, or test for the existence of a key, in that namespace? Note that relying on $E:vname expanding to an empty string is not the same thing as knowing if the env var is set, even if set to the empty string.

@krader1961
Copy link
Contributor Author

Treating the $e: namespace (external commands) like other namespaces might be a bridge too far because you can already do the equivalent of has-key $e: prog via has-external prog. However, I would argue that has-external is redundant if you can treat $e: as a read-only Elvish map usable by has-key and keys.

@krader1961
Copy link
Contributor Author

Regarding the e: namespace for external commands. Note that if it could be treated like a readonly Elvish map then doing $e[a_command] would evaluate to the command path that would be used if you ran e:a_command. That would be extremely useful.

@hanche
Copy link
Contributor

hanche commented May 16, 2020

The has-env command does exist, and mitigitates this issue a bit, just as has-external does for the e: name space.

Also as for the immediately preceding comment, search-external already does that.

But still, I agree that it could be handy to have e: and E: behave more like other namespaces. Personally, I'd like to even see the top-level interactive name space in the same way, but that is perhaps because I am a big fan of introspective capabilities (even if there is always a potential for misuse).

@krader1961
Copy link
Contributor Author

Thanks, @hanche, as I had overlooked the has-env and search-external commands. Nonetheless, I think we both agree the magic builtin namespaces, such as e: and E:, shouldn't behave differently from a namespace created by the use command. Specifically with respect to builtins like keys, has-key, and indexing into the namespace.

@xiaq
Copy link
Member

xiaq commented May 17, 2020

I was too lazy to implement introspection operations on $E: (it doesn't even exist), but someone (or I, eventually) should do that, and remove the *-env builtin functions (after deprecation).

FWIW, namespaces and maps are distinct types in Elvish. Namespaces are reference types with a fixed set of keys while maps are value types.

@xiaq xiaq changed the title Shouldn't the E: namespace be an Elvish map? Supporting introspecting $E: as if it were a normal namespace May 17, 2020
@xiaq xiaq added this to the 0.15 milestone May 17, 2020
@xiaq xiaq removed this from the 0.16.0 milestone Oct 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants