Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!seismo!mcvax!enea!sommar
From: sommar@enea.UUCP
Newsgroups: comp.os.vms
Subject: Re: Contemplations on CDU
Message-ID: <1973@enea.UUCP>
Date: Mon, 8-Jun-87 09:45:05 EDT
Article-I.D.: enea.1973
Posted: Mon Jun  8 09:45:05 1987
Date-Received: Thu, 11-Jun-87 00:50:40 EDT
Reply-To: sommar@enea.UUCP(Erland Sommarskog)
Followup-To: comp.os.vms
Organization: ENEA DATA Svenska AB, Sweden
Lines: 75

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