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 BITNETsommar@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