In a recent note, Skip Robinson said:
> Date: Fri, 10 Feb 2006 16:26:47 -0800
>
> I wouldn't characterize CLIST as 'always ignoring the first ampersand'. The
> ampersand in
>
> SET &COLOR = RED
>
> is *optional* because the position of the term to the left of the equal
> sign marks it as a variable regardless of whether the ampersand is coded.
> That is, only a variable could possibly occupy that position. Hence this
> statement is equivalent:
>
> SET COLOR = RED
>
Ouch! Dreadful design to deliberately introduce an ambiguity!
I thought the topic of this thread is that CLIST supports
generated variable names. But, then, how do I assign to the
variable whose name is the content of "COLOR"? Let me see
if I understand this:
SET RED = 'WOMBAT'
SET COLOR = RED
PRINT &&COLOR /* Prints 'WOMBAT', Doesn't it? */
But:
SET RED = 'Uninitialized'
SET COLOR = RED
SET &COLOR = 'WOMBAT'
PRINT &&COLOR /* Prints what? I'd hope for 'WOMBAT'. */
Even as in C:
int *p;
p = 42; /* Converts 42 to a pointer and assigns it to p. */
*p = 42 /* Stores 42 in the integer object pointed to by p. */
Leading content-of operators can _not_ be ignored, not even in
L-value contexts.
Perhaps someone will provide a PL/I example. I'm curious how
that works.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html