Closed stuhlmueller closed 7 years ago
I support this. It would be very useful for running batched scripts (e.g., when bootstrapping priors for models) especially on a cluster
One idea is to use --
to delimit webppl arguments from program arguments. i.e. we could take anything that comes after the first --
to be arguments of the program, and put those in a new global variable, argv
say.
This ensures that changing the number of arguments passed to webppl
doesn't change the arguments made available in the program.
For convenience, we might also parse these arguments with minimist. (Which we're already using internally.) This would parse the arguments into a dictionary, which is probably easier to work with than an array of strings.
For example, I'm imagining that running:
webppl program.wppl --require webppl-viz -- elbo --steps 100 --restart
Would make the following object available as a global in the WebPPL program:
{ _: [ 'elbo' ], steps: 100, restart: true }
Also, note to self, the idea of having an official way of getting at the filename of the current program came up recently. We might tackle that as part of this.
Would it violate expectations to have arguments before the program name be arguments to WebPPL, and ones after to the program? In that case, the equivalent of your example would be:
webppl --require webppl-viz program.wppl elbo --steps 100 --restart
Would it violate expectations to have arguments before the program name be arguments to WebPPL, and ones after to the program?
Not too surprising, I think Node does something similar. I think the main draw back would be that it's not backwards compatible. I'm not sure how big of a deal that is.
Also, for the common case of running a program without program arguments, it seems useful to have the webppl arguments floating at the end of the command, since it makes them easy to modify when re-running programs using shell history etc. This is a pretty minor convenience though.
On the plus side, not having to introduce the special --
separator is a win.
Using
process.argv
we can access additional command line arguments in webppl scripts. For example, withtest.wppl
only containingprocess.argv
:There is currently no guarantee that future changes won't break this (e.g. if we started to throw errors when the webppl script receives extra positional parameters). We might want to document and officially sanction it.