On Wed, Mar 7, 2018 at 2:08 PM, Evan Harris <auctionitis@xxxxxxxxx> wrote:
On Wed, Mar 7, 2018 at 8:01 PM, John Yeung <gallium.arsenide@xxxxxxxxx>
wrote:
On Tue, Mar 6, 2018 at 5:21 PM, Evan Harris <auctionitis@xxxxxxxxx> wrote:
I rarely go more than 1 or 2 parameters on the command line without
specifying the option as well
One or two parameters is generally all you need for CL *programs* also.
That's not my experience; I have written a lot of CL programs and plenty of
them used more than a couple of parameters. Anything beyond trivial is
likely to wind up with at least one command with more than a couple of
parameters.
I finally see where the disconnect is. I am talking about whether the
parameters you use need to be specified by keyword or not. If you
don't need the keyword, then I generally prefer to leave the keyword
off.
The parameters which don't require a keyword are referred to as
"positional" (because they can be inferred purely by their position),
and there are usually very few of these for any given command, no
matter how many total parameters are available for that command.
I should have given examples right from the beginning, but I didn't
have a connection to an i at the time to check my work. I am guessing
you aren't the only one who would understand me better with an
example, so here goes.
If you let SEU's prompter format your ADDPFTRG command, you'll get
something like this:
ADDPFTRG FILE(CMC2) TRGTIME(*AFTER) TRGEVENT(*INSERT) +
PGM(ASL1106R)
Whereas I prefer it to look like this:
ADDPFTRG CMC2 *AFTER *INSERT PGM(ASL1106R)
Not only have I left off some of the keywords, I've also positioned
the statement closer to the left edge. (I would indent it if it were
within a DO..ENDDO block.) The shorter version takes up just one line
instead of two, and its meaning is, in my opinion, just as clear as
the longer version.
Now, this particular command happens to accept a relatively high
number of positional values. As it turns out, even the PGM keyword
isn't required (my shop is at 7.1 in case that makes a difference), so
it has at least four positional (keyword-optional) parameters.
But in this case I find that including PGM has sufficient value to
justify the extra verbosity. (1) The cost in verbosity is pretty low.
IBM could have chosen the costlier PROGRAM instead of PGM. (2) I can
see how someone's intuition might be to specify the program instead of
the file as the first parameter. So the keyword provides a noticeable
benefit in terms of disambiguation.
Whereas TRGTIME and TRGEVENT are, to me, relatively expensive and do
not provide any disambiguation, due to the restrictions on the
possible values. If you even know what a trigger is, you won't be
wondering whether *AFTER is a file or a program or an event. It could
only reasonably be a time. This is what I mean when I say a keyword is
"obvious".
So, I think that was perhaps a painfully detailed run-through of my
thought process when I am writing CL, but hopefully that clears up for
some people what is going through my mind, and what the heck I am
talking about.
I have no problem with people having a different sense of what's
aesthetically pleasing or what's readable. I'm quite sure I'm in the
very, very small minority in my CL tastes. But I do like for people to
understand me, so that they know what they are disagreeing with. ;)
I have no
idea why your prettifier would need to know anything about which
unnecessary options it could safely remove. By defintiion anything in the
CL program is required because it has been specified (at least in my
experience).
Hopefully you get it now. The prettifier has to know which KEYWORDS
are optional. That is, it has to know which parameters can be
specified purely by position. If it encounters any other keyword-value
pairs, it can safely assume that the keyword is required. And as
demonstrated above, I might want to hand-tweak the prettifier so that
it doesn't automatically remove everything that the compiler would
allow to be removed (such as the PGM keyword for the ADDPFTRG
command).
John Y.
midrange.com
