[comp.os.vms] Contemplations on CDU

sommar@enea.UUCP (Erland Sommarskog) (05/30/87)

CDU is a nice facility, really useful for defining your own commands.
However, I'm not really on terms with it in some cases. Look at the 
following excerpt:
   Define type DESCRIPTION_WORDS
       Keyword HEADER  deafult, nonnegatable, value(default=0)
       Keyword FOOT    deafult, nonnegatable, value(default=0)
       Keyword PAGE    deafult, nonnegatable, value(default=0)
   ...
   Qualifier DESCRIPTION
             Default,
             Nonnegatable,
             Value(Required, List, Type = DECSRIPTION_WORDS)
             
As long I do not use the qualifier it's OK. I just do a CLI$Get_value
for each of them and get zeroes in return. But if I give the command:
    $ UTILITY/DESC=HEAD:3
the calls to CLI$Get_value for FOOT and PAGE return empty strings and
CLI$_ABSENT!
  OK, there at least two ways around this. I could split the qualiifier
into three, but I don't want to have too many qualifiers. That just
confuses the user, when he is reading the help text. And there are cases
when the workaround isn't possible. 
  The other way is to move the default values into the programme. But
I think that in this way you lose a bit of the idea of CDU. If I can keep
the default values to the CLD-file, I don't have to recompile and relink
to change them. Individual users might even have their own defaults if 
they have access to the command defintion.
  I haven't studied the manual carefully on this point, so I can't really
tell if it is a bug or a feature. But my personal opion is that is 
a bug and nothing more, and thus deserves an SPR. What do you think?

-- 
Erland Sommarskog       
ENEA Data, Stockholm    
sommar@enea.UUCP        
                        

SLOANE@UKANVAX.BITNET (BOB) (06/05/87)

Erland Sommarskog, ENEA Data, Stockholm gives the following CLD example:

   Define type DESCRIPTION_WORDS
       Keyword HEADER  default, nonnegatable, value(default=0)
       Keyword FOOT    default, nonnegatable, value(default=0)
       Keyword PAGE    default, nonnegatable, value(default=0)
   ...
   Qualifier DESCRIPTION
             Default,
             Nonnegatable,
             Value(Required, List, Type = DESCRIPTION_WORDS)

and comments that CLI$GET_VALUE returns a null string for FOOT when
/DESC=HEAD:5 is entered.

It seems to me that HEADER, FOOT and PAGE are VALUES that the /DESC
qualifier can have.  As such, I doubt that the DESC qualifier should
take on more than one value by default.  What you really have is 3
different qualifiers here, not just one qualifier that can take different
values.  Users not only have to remember the FOOT, HEADER, and PAGE values
but also the /DESC Qualifier.  If I were using a program with this syntax
I would rather just remember 3 things, not 4. It seems to me that the DESC
qualifier is redundant and could be eliminated.

                      Bob Sloane
                      University of Kansas
                      Computer Center
                      (913) 864-4291
                      SLOANE@UKANVAX on BITNET

sommar@enea.UUCP (06/08/87)

Bob Sloane (SLOANE@UKANVAX.BITNET) questions the CLD example I gave in 
article a little more than a week ago:

   Define type DESCRIPTION_WORDS
       Keyword HEADER  default, nonnegatable, value(default=0)
       Keyword FOOT    default, nonnegatable, value(default=0)
       Keyword PAGE    default, nonnegatable, value(default=0)
   Qualifier DESCRIPTION
             Default, 
             Nonnegatable,
             Value(Required, List, Type = DESCRIPTION_WORDS)

With /DESCRIPTION=HEAD:3, I get null strings when I retrieve PAGE and FOOT
with CLI$Get_value.

Bob writes:
>It seems to me that HEADER, FOOT and PAGE are VALUES that the /DESC
>qualifier can have.  As such, I doubt that the DESC qualifier should
>take on more than one value by default.  What you really have is 3
>different qualifiers here, not just one qualifier that can take different
>values.  Users not only have to remember the FOOT, HEADER, and PAGE values
>but also the /DESC Qualifier.  If I were using a program with this syntax
>I would rather just remember 3 things, not 4. It seems to me that the DESC
>qualifier is redundant and could be eliminated.

I wrote:  
>  OK, there at least two ways around this. I could split the qualifier
>into three, but I don't want to have too many qualifiers. That just
>confuses the user, when he is reading the help text. And there are cases
>when the workaround isn't possible. 

Thus, I did state I didn't like Bob's idea, and also shortly why. Since it 
may be of general interest, I'll develop these reasons. First an example of
when I find it impossible to have separate qualifiers:

   Define Type CHAR_NAMES                  Qualifier WORD_CHARS,
   keyword HYPHEN, default, negatable                Default,
   keyword NUMBERS, default, negatable               Nonnegatable
   keyword UNDERSCORE, negatable                     Value(Required, List,
   ... ! 20 more no-default and negatable                  Type = CHAR_NAMES)
   keyword ALL, nonnegatable
   
If I enter /WORD_CHAR=(UNDERSCORE), HYPHEN and NUMBERS are suddenly absent.
Since I'd like to tell the user: "Hyphen and number are considered as
word characters unless you negate them", I have to move the default into
the programme. Or do anyone think I should have separate qualifiers? (Before
you send me your advice: I have already replaced CHAR_NAMES with a string
parameter instead.) 

Bob is perfectly right in that PAGE, HEADER and FOOT semantically are three
different qualifiers. But as I said, I don't want to mess up the help text.
Do for instance HELP PRINT and you'll understand why. Mixed up with the 
spceific PRINT qualifiers (about 7-10 I think) there are the general file 
selection qualifiers (/BY_OWNER, /CONFIRM and 5-6 more). If you're looking 
for a qualifier to help you, you can't see the wood for the trees. (I think 
DEC should fix this by having a file-selection entry or something like that.)
  The task of my programme is to generate a frequency word list of a text.
To be able to detect syllabications across page boundaries, I must know
how the infile looks like so I can skip page headers and "footers". Thus,
it is likely that you'd use these three together. (PAGE is needed when
there is no form feeds.) And since I don't consider this as the most im-
portant feature of the programme, I have grouped them with help of
/DESCRIPTION. Of course, it's a matter of taste, but I hope you understand
the rationale although you wouldn't have done the same. Apparently, DEC
does not share my point of view, since it doesn't work as I want to.

(By the way, could this frequency word-list programme be of general
interest? It's not for sale, just for give-away. Good as a spell-checking
aid in several languages.)

-- 
Erland Sommarskog       
ENEA Data, Stockholm    
sommar@enea.UUCP        
                        

tedcrane@batcomputer.UUCP (06/08/87)

In article <8706060828.AA10670@ucbvax.Berkeley.EDU> SLOANE@UKANVAX.BITNET (BOB) writes:
>Erland Sommarskog, ENEA Data, Stockholm gives the following CLD example:
>   Define type DESCRIPTION_WORDS
>       Keyword HEADER  default, nonnegatable, value(default=0)
>       Keyword FOOT    default, nonnegatable, value(default=0)
>       Keyword PAGE    default, nonnegatable, value(default=0)
>   ...
>   Qualifier DESCRIPTION
>             Default,
>             Nonnegatable,
>             Value(Required, List, Type = DESCRIPTION_WORDS)
>.....
>It seems to me that HEADER, FOOT and PAGE are VALUES that the /DESC
>qualifier can have.  As such, I doubt that the DESC qualifier should
>take on more than one value by default.  What you really have is 3
>different qualifiers here, not just one qualifier that can take different
>values.  Users not only have to remember the FOOT, HEADER, and PAGE values
>but also the /DESC Qualifier.  If I were using a program with this syntax
>I would rather just remember 3 things, not 4. It seems to me that the DESC
>qualifier is redundant and could be eliminated.

Bob expresses a point of view that many folks agree with.  However, I have
run up againast a few cases where the opposite is true.  The best example
uses the good ol' DCL command, DIRECTORY.

Right now, DIRECTORY has a large number of qualifiers whose purpose in life
is to select files based on some criteria.  For example, "/SINCE", "/OWNER_UIC",and the like.  There is also one whose syntax is actually:
	/SELECT = SIZE={MIN,MAX} [=size]
In the case of qualifiers which "select", then wouldn't it be more
obvious to say
	/SELECT=(SIZE=something,DATE=SINCE=something,OWNER=something)
in other words, to group all the selections?

Similarly, to group all the display items?
	/DISPLAY=(filename,size,creation_date....)

Well, anyway, there are two ways to look at it.  In some cases a hierarchical
approach as suggested in the original article is appropriate.

SLOANE@UKANVAX.BITNET.UUCP (06/10/87)

Regarding Erland Sommarskog's CLD example, the problem seems to be in
the definition of the word DEFAULT.  I think of DEFAULT as meaning the
value that is supplied by the system WHEN NO VALUE IS GIVEN. If the user
enters some value, then no DEFAULT value should be used. In the example:

   Define Type CHAR_NAMES                  Qualifier WORD_CHARS,
   keyword HYPHEN, default, negatable                Default,
   keyword NUMBERS, default, negatable               Nonnegatable
   keyword UNDERSCORE, negatable                     Value(Required, List,
   ... ! 20 more no-default and negatable                  Type = CHAR_NAMES)
   keyword ALL, nonnegatable

Erland would like HYPHEN and NUMBERS to always be in the list, even though
only UNDERSCORE was entered by the user, as if DEFAULT means that these values
are always in the list BY DEFAULT, not that they are DEFAULT VALUES used by
system when no other value is given. I think either definition is valid.
Suppose, for example, that I was writing the same program as Erland, but for
WORD_CHARS I wanted the default to be ALL, not HYPHEN and NUMBERS.  Then the
program would have to know that the ALL option should only be processed when
there were no other options present.  It would be nice to have it both ways,
but that would mean adding an new option to CDU. In any case, I do not think
that this is a bug in CDU, which was the original question.

                      Bob Sloane
                      University of Kansas
                      Computer Center
                      (913) 864-4291
                      SLOANE@UKANVAX on BITNET