Support passing arguments to scripts from command line

[pmachata]

The immediate idea is to use $1, $2, etc. to refer to first, second, etc. command line argument.

Another possibility, maybe more in line with how dwgrep generally operates, is to have a word like argv that yields individual command line arguments. One could say things like argv (pos == 0) to get a particular one. That's less handy and I'm not sure passing arbitrary command line lists is useful. In the end, both can be present.

• These would have to be passed in not only from command line, but also from the C and C++ wrappers. While C and C++ wrappers could pass in arbitrary value subclasses, only strings would come from the command line.
• Systemtap has @1, @2, etc. for literals. $1, $2, etc. are pasted verbatim (macro-expanded so to speak) and lexed and parsed. This would allow the "17" be passed in as 17, "DW_AT_name" as DW_AT_name, etc. But we use @ for attribute access, and we might want to use @1 for access to location expression values (where currently you have to awkwardly type value (pos == 0)), macro arguments or possibly other things like that. Maybe we just need a word eval.
• These could act like variables defined in outermost scope, which would simplify referencing them. Type inference (when/if it's done) would have to be done after these arguments are provided.
• Command line interface would have to be changed so that it's clear where the arguments come from. We could use --args like GDB does. We shouldn't break the use case where one just dumps a bunch of files to dwgrep through to command line, such as dwgrep 'my query' $(find my files). That shouldn't translate to a bunch of script command line arguments.

[pmachata]

Another possibility is that command line arguments are passed on the stack, and lexical scopes are used to bind them:

(|arg1 arg2 arg3|
 foo bar baz program)

After binding the command line arguments, TOS contains the Dwarf object as is usual when no command line arguments are present.

A disadvantage of this approach is that an unexpected command line argument completely derails the execution (the Dwarf object is not where it's expected), and passing variable number of arguments basically can't be done. A word such as argc might mitigate this somewhat, a word for access to nth stack sloth would help as well. Fundamentally, while this looks very cool, it's not as simple.

[pmachata]

Actually I don't think it's that much of a problem that varargs are not supported. It is always possible to simply pass in an array as one argument.