I think that the stem solution, below, should be taken in the spirit of fun, as it was undoubtedly meant. It appears to have been an extreme, absurd example of how one can "overcode" a solution. (Why do it in a single statement if you can write a chapter in a book to do the same thing?) Strunk and White championed precision, brevity and clarity in business communications in "Elements of Style". Their advice applies to programming as well to letters, notes, and e-mail.
Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Chip Davis > Sent: Tuesday, July 08, 2008 5:19 PM > To: [email protected] > Subject: Re: REXX coding question. > > [NOTE: This thread has gone well beyond being of any use to > the OP, however it may have pedagogical value to others. Maybe.] > > As big a fan of Rexx stem associative arrays as I am, I > should emphasize that none of the below _enhances_clarity_. > In fact, one could safely argue that it raises the Rexx > Astonishment Factor quite high. > > That said, the OP was dealing with only a binary ("yes" vs > anything else) case. > Another way to code for multiple positive responses would be: > > Parse Value 01 I WILL GROVEL With 1 _. 2 _.Y . 2 _.YE . 2 > _.YES . , > 2 _.OKAY . 2 _.PLEASE . > 2 _.SURE . , > 4 phrase 2 _.phrase . > > Say "Should I do this?" > Parse Upper Pull answer > > If _.answer Then Say "I will do it." > Else Say "I will not do it." > > Not that I am espousing this sort of programming (there is > such a thing as giving the user too many options) but the > PARSE instruction packs quite a bit of power and will usually > perform multiple assignments faster than multiple assignment > statements. > > -Chip- > > On 7/8/08 14:45 Kris Buelens said: > > Beware: now I will pop in: > > The _. stem was initalized to '' (nullstring) consequently > there is no > > need to check with SYMBOL() > > > > Futhermore when coding SYMBOL('_.'answer) you will get a double > > translation, if it were required/better, one should code > > > > When symbol('_.answer')<>'VAR' then .... > > > > With your SYMBOL() code, an answer like I GROVEL BEFORE YOU > TO PERMIT > > IT will be refused > > > > 2008/7/8 Brian Nielsen <[EMAIL PROTECTED]>: > >> Before someone dings me for it, the SELECT below should > have this as > >> the > >> > >> first WHEN clause: > >> > >> WHEN symbol('_.'answer)<>'VAR' > >> THEN say 'Invalid answer' > >> > >> > >> Brian Nielsen > >> > >> On Mon, 7 Jul 2008 16:51:27 -0500, Brian Nielsen > >> <[EMAIL PROTECTED]> > >> > >> wrote: > >> > >>> On Mon, 7 Jul 2008 20:26:50 +0000, Chip Davis > <[EMAIL PROTECTED]> wrote: > >>> > >>>> In fairness, your problem is not caused by unfamiliarity with > >>>> formal logic, but mere lack of clarity. > >>> Brings back memories of the obfuscated C contest. Some of those > >>> entries were brilliant. > >>> > >>>> If I might suggest an alternative so far overlooked: > >>> And here is another (obscure) alternative that also > allows phrases > >>> and synonyms without complicated logic tests: > >>> > >>> /* */ > >>> > >>> _.='' > >>> _.y='Y' > >>> _.ye='Y' > >>> _.yes='Y' > >>> _.okay='Y' > >>> _.please='Y' > >>> _.maybe='Help' > >>> phrase='I GROVEL BEFORE YOU TO PERMIT IT' > >>> _.phrase='Y' > >>> phrase='YOU ARE CRAZY IF YOU THINK I WANT TO DO THAT' > >>> _.phrase='N' > >>> > >>> say 'Should I do this?' > >>> pull answer > >>> > >>> SELECT > >>> WHEN _.answer='Y' > >>> THEN say 'I will do it' > >>> WHEN _.answer='N' > >>> THEN say 'I will not do it' > >>> WHEN _.answer='Help' > >>> THEN say 'RTFM and make up your mind' > >>> OTHERWISE say 'Invalid answer' > >>> END > >>> > >>> > >>> Brian Nielsen > >>> ======================== > >> ========================= > >> ======================= > >> > > > > > > >
