I was attempting to show the usefulness of stems. I did a quick and dirt
y
assignment of values in the example because how the values got there was
not what I was trying to show. In putting together a simple example
quickly from several real EXEC's I made some compromises.
In many of my EXEC's I have to dynamically extract an unknown number of
unknown values from a report. Stems give an easy way to organize the
extracted data and track whether a particlar value has been seen before o
r
not. My appologies for inadvertantly mixing different techniques for
detection of new values (null assignment vs. using SYMBOL).
And I agree this, is beyond usefullness to the OP.
Brian Nielsen
On Wed, 9 Jul 2008 00:18:42 +0000, Chip Davis <[EMAIL PROTECTED]> wrote:
>[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]> wrot
e:
>>>>
>>>>> In fairness, your problem is not caused by unfamiliarity with forma
l
>>>>> 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 a
nd
>>>> 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
>>>> =======================
=
>>> =======================
==
>>> =======================
>>>
>>
>>
>>
>========================
=========================
========================
