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