Date:         Tue, 6 Jun 2000 16:37:43 -0500
Reply-To:     Jonathan_Goldberg@MASTERCARD.COM
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Jonathan Goldberg <Jonathan_Goldberg@MASTERCARD.COM>
Subject:      Re: Referencing Macro Variables
Content-type: text/plain; charset=us-ascii

  owen_meany@rocketmail.com wrote:
> I've created global macro variables that I can reference directly,
but I
> can't figure out how to do it using do loops.
>
> Here's a quick abbreviated example:
>
> Data Temp;
> input ID $1. B1000 B1100 B1200 B1300;
> cards;
> A 10 20 30 40
> B 50 60 70 80
> C 05 10 15 20
> ;
> run;
>
> Data _Null_;
>   call symput('List1','B1000, B1100');
>   Call symput('List2','B1200, B1300');
> run;
>
> It works fine if I reference the macro variables directly:
>
> Data Analyze;
>   Set Temp;
>   SumList1=Sum(&List1);
>   SumList2=Sum(&List2);
> run;
>
> However, this doesn't work:
>
> Data Analyze;
>   set Temp;
>
>   Array SumList (2);
>
>   do x = 1 to 2;
>     SumList(x)=sum(&List(x));
>   end;
> run;
>
> I'd prefer using arrays and do loops since I've got a lot of summing
to
> do.
>
> Any suggestions?
>
> Thanks
>
> Dan
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>

This posting raises interesting questions about the nature of SAS.

To my mind is quite reasonable to wish to write:

   do x = 1 to 2;
    EXECUTE sumlist(x) = sum(%symget('list' || trim(left(put(x, 4.))));
   end;

However, there is no such thing as EXECUTE.  The execute call routine stacks
code in the scanner input queue for processing after the end of the data step.
SAS's compile and go architecture seems to militate against a construct in which
code is dynamically generated and then executed on the fly.

In other languages (e.g. PERL, LISP, REXX, etc.) this sort of thing is
commonplace.  Although obviously workarounds are possible (and Ian has posted
one), such a capacity would be a worthwhile extension to SAS.

I wouldn't be surprised if Dan is used to programming in such a language.
Sometimes it takes an outside view to remind us that our ways of looking at
problems can become constricted by the, perhaps arbitrary, limits of our tools.

Jonathan