A long time ago, earl and I discussed the concept of making it so that a script's header would use something like the function spec dialect to define the command line arguments for a script. So if you declared a refinement like /foo [integer!] that would be translated into something appropriate for your platform, like an argument to your script taken as --foo=3 on Linux or /foo 3 on Windows. Or whatever.
Regular args would be required arguments, you'd get automatic help from the string descriptions in the spec, etc.
Red's Boris has done nearly exactly this...but he isn't putting a spec into the script header. He has you make a function and then pass that function to a CLI dialect processor:
I do still like the aesthetics of putting it in the script header; it feels like a good place. Though that would bake it in somewhat more...and introduces the question of what scope the arguments are in. Would you have to say system.processed-args.foo, or would it be a globally scoped foo to the whole script?
And he mentions a good point of making this something you can apply to any function:
"You can turn any Red function into a command line utility with one or two words. Suppose you have a
grepfunction that is to be used from Red. Prefix it with
That is worth thinking about. You can say --do "..." on the command line to run arbitrary code, but what if you could specify a script name and say --function "func-name", and have that function suddenly get its arguments from the command line?
If that sounds dumb compared to --do "func-name/refine arg1 arg2" just consider that sometimes you do want to integrate with the shell, and getting arguments spliced via the shell into such a --do string can be a mess. It also can't be aliased into a single shell command.
Anyway, their experience with this is worth looking at, as it's something I've wanted for a while. Whether there's a way of offering this in a script's header or not, I think I'm sold on the "you should be able to do it to any function if you want" angle.