@giuliolunati made an interesting change recently to the %make.r process in which it would allow you to use param: value instead of param=value on the command line.
One of the motivations was auto-completion in shells. If you have your cursor _ sitting at the end of something, so r3 foob_ and hit tab, it will complete to r3 foobar.txt. But if you have r3 param=foob_ you will not get this behavior.
So breaking it up has a benefit there (as long as your command line processing doesn't require a % on filenames, because completion in shells like bash won't work with that).
Question #1: Do we need to support both synaxes in %make.r? I say no...we are already fighting quite a lot of complexity, and that means more code as well as more variations in documentation. Given that it is friendlier to autocomplete I suggest we adopt @giuliolunati's method--unless anyone can think of a good reason not to.
This raises some questions, however, about things like --help. Presumably we don't want help: yes to be how you ask for HELP. But to go with a more Rebol-like syntax, a refinement e.g. /help could be more sensible, in the same way that a: b makes more sense than a=b for assigning a parameter value.
Question #2: Beyond the special-purpose %make.r...for which we can use whatever rules are most convenient...should the interpreter itself use more of a LOAD-able syntax in general? What about best practices for Rebol command line apps?
In its own command line, Rebol already avoids using =, so it's --do "print {Hi}" and not --do="print {Hi}". This isn't done for LOAD-ability, though it similarly makes parsing a little bit easier.
Here's some background reading on people's ideas about best practices for command lines. Unsurprisingly, the suggestions are "be consistent with everything else", so they advocate for supporting --help and --version, the -- to end options and start formal arguments, etc.:
I don't know about all the nuances, but as this stuff is now usermode code it offers the opportunity to experiment with different ideas.
