SYSTEM.OPTIONS.ARGS vs. SYSTEM.SCRIPT.ARGS

Development Modules
1

I was looking at some code like:

tests: if try first system.options.args [
    local-to-file first system.options.args
] else [
    %core-tests.r
]

And it reminded me that I don't like the nuance between SYSTEM.OPTIONS.ARGS and SYSTEM.SCRIPT.ARGS.

One of them is supposed to capture the command line arguments that spawned the interpreter. The other is the arguments to the currently running script. If you spawn the interpreter in such a way that it runs a script, then the two will be the same when that script runs.

I Don't Like the Naming Distinction or the Behavior

It seems flawed to me that you can confuse them (and many people do, in ways that break as their code gets more complex.) One way to avoid confusion would be to say that all arguments should go one place or the other.

e.g. drop the idea of giving you verbatim what the command line was. If you write the command line in such a way that some arguments are given to the script, then remove those from the place where you find the spawning arguments.

That would give us SYSTEM.BOOT.ARGS which is everything that didn't get picked off to pass to the script. And the script gets SYSTEM.SCRIPT.ARGS.

Should There Be SYSTEM.BOOT.ARGS At All?

I don't know if it's even a good idea. Why should you be looking at that, vs. whatever was gleaned from it? This just seems like a way to start building dependencies on the command line argument conventions of the executable that are none of your script's business.

Anyway, maybe I am wrong and SYSTEM.BOOT.ARGS giving you an exact capture of the arguments which started the executable is useful and should be preserved. :man_shrugging: I'm just annoyed at how often I've been bitten by this and maybe overreacting.

But at least renaming it to SYSTEM.BOOT.ARGS helps you avoid confusing it. The SYSTEM.OPTIONS.ARGS vs. SYSTEM.SCRIPT.ARGS naming hath wrought nothing but pain.

1 Like