Feature: Add symbols for interpreter, program, and script

[aghast]

As things presently stand, the following files can all be different:

• the "installed" hush interpreter (installed via cargo install)
• the "running" hush interpreter (perhaps due to cargo test in a hush git repo)
• the current "hush program" being run (invoked with hush foo.hsh)
• the current hush-script file being executed (perhaps via std.import("bar.hsh"))

In many cases (most cases?) the first two will be identical. If they are not identical, the user
probably doesn't actually care about the installed interpreter.

In many cases the last two will be identical. If they are not identical, it matters and the coder had better be able to figure out what he wants to talk about. (Are we talking about my library, or your program that uses my library.)

Some languages (e.g., python) hide this stuff in a sys. namespace. This is not quite standard-library stuff, since the data is subject to change a lot. Bash, and GnuMake, tend to treat the last two as the opposite ends of a stack or list, with the "program" being the root of the stack and the current script being the leaf. C provides __FILE__ for one and nothing for the other, although glibc provides different versions of the program name (and __FILE__).

IMO this is a language-design issue. It makes sense to have a standard way to get this data, but it could be the result of a function call (std.interp_info()) or it could be a separate dict/namespace (sys.interpreter, sys.argv0, sys.this_file) or it could be special variables, a la Perl5: $#, $^P, etc.

[gahag]

Hmm, makes sense. For the current script path, we can easily implement an std function that returns it as a string. The call site information is readily available and includes the source position, which contains the path. As for the root script, It won't be so straightforward, but I believe we can extract that info from the Runtime. I believe these two std functions would be the best approach, as opposed to a global dict. Let me know what you think.

[aghast]

Maybe one std.interp_info() function that returns a dictionary with various fields? That way, when more of these things come up they can just be added to the dictionary.

[gahag]

Sound good to me!