New behaviour for command modifiers

[DanB|Dyalog]

SALT and User Commands use the same parser to make sense of the string given as argument.
The parser splits the string into tokens using the spaces or dash (-) as delimiters.
If any token includes spaces you must enclose the token in quotes or double quotes.
So the string

Code: Select all

arg1 'arg 2' -mod1 -mod2=1 2 3 -mod3=abc

is split into 5 tokens: [arg1], [arg 2], [-mod1], [-mod2=1 2 3] and [-mod3=abc]

Here mod2 accepts a value of '1 2 3' and mod3 accepts a value of 'abc'.
Notice you don't need to put quotes around '1 2 3' because the parser understands that it goes together.

Would anybody object to HAVE TO put quotes around modifier values if they have spaces in them?

[ray]

In short my answer:
I would not object, but would expect some code will be broken by the change.

Please excuse the rambling, I am now thinking aloud....

I assume "arguments" cannot start with a leading "-" character.

I also assume all "arguments" have to come before any "modifier", otherwise the 2 and 3 of [-mod2=1 2 3] would be read as two more "arguments". ("because the parser understands that it goes together")

I believe:
All "arguments" are "positional" that is their order is important (but "trailing" arguments may be optional);

While all "modifiers" are optional and must have a leading "-" followed by a "keyword" and possibly a "=" then a value, but can be supplied in any order after the arguments.

With the proposed change, "modifiers" could be allowed to be in any position, as once "stripped out" it would leave just the supplied arguments in their positional order.

This is how I seem to remember IBM's JCL (job control language) used to work 30 or 40 years ago, so it "feels" right to me.

As with System commands (and comments) the leading "]" or ")" or "⍝" tell the parser not to execute items to the right. Hence, in the example, quotes are not required around the mod3 character string abc.

However, when a user command is executed within code via ⎕SE.UCMD, the right hand argument is an APL character string, so the example would change from

]foo arg1 'arg 2' -mod1 -mod2=1 2 3 -mod3=abc

to
⎕SE.UCMD 'foo arg1 ''arg 2'' -mod1 -mod2=1 2 3 -mod3=abc'

or using double quotes (rather than 2 single quotes)
⎕SE.UCMD 'foo arg1 "arg 2" -mod1 -mod2=1 2 3 -mod3=abc'

With your proposed changes, this would become

]foo arg1 'arg 2' -mod1 -mod2='1 2 3' -mod3=abc

to
⎕SE.UCMD 'foo arg1 ''arg 2'' -mod1 -mod2=''1 2 3'' -mod3=abc'

or
⎕SE.UCMD 'foo arg1 "arg 2" -mod1 -mod2="1 2 3" -mod3=abc'


My first thoughts raised this question:
How does the User Command (parser) currently tell the difference between a numeric value and a character string being passed as a modifier? (Or is that N/A, as all "tokens" are always character strings?)

I think the latter: "tokens" are always character strings. So the parser does not need to worry about numerics versus characters.

Question: After the change, if your (unaltered) string was supplied, would the parser reject the whole string as an error, or return 7 tokens:
3 tokens as modifiers
[-mod1] [-mod2=1] [-mod3=abc]
and 4 tokens as positional arguments:
[arg1] [arg 2] [2] [3]


OK. Back to your question "Would anybody object to HAVE TO put quotes around modifier values if they have spaces in them?"

If an error is reported by the parser, when typed in at the terminal any "]" user commands should not be a major problem, as they can simply be re-entered by the user. If an error is not reported, I would expect the user command code would crash, but again not a very big deal.

However, some existing code (using ⎕SE.UCMD) could be broken if this change is made.

Do many people use ⎕SE.UCMD?
I know I do in setting PFKeys and some other tools, although I don't think any of my code would require changes.

Some user commands might themselves use ⎕SE.UCMD within their own code!

[DanB|Dyalog]

Ray, you are correct about the possibility that some code is relying on this and this is the reason for this post: how many people think this would change their life?
In my experience very few but I'd like to know.

About your thinking assumptions: for the most you are also correct:
arguments come before modifiers but there are no OPTIONAL trailing arguments (although you can specify a range of arguments, say 3 to 5).
The same rule would apply to ⎕SE.UCMD and the example would become (note the quotes around mod2's value)

Code: Select all

⎕SE.UCMD 'foo arg1 ''arg 2'' -mod1 -mod2="1 2 3" -mod3=abc'


The parser does not try to interpret modifier (or argument) values and always returns a string. (Note the function Switch, returned in the result of the Parse method, still allows you to turn those values into numbers). This would remain the same.

After the change the parser would now return 4 arguments instead of 2 and mod2 would contain ,'1' instead of '1 2 3' as you predicted. Subject to the ucmd parsing rules of course (it could now be rejected if, e.g. the number of arguments was set to 2).

Current user commands call themselves but this problem does not present itself. That would be safe.
/Dan