LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (August 2000, week 3)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:         Tue, 15 Aug 2000 09:39:39 -0700
Reply-To:     Puddin' Man <pudding_man@ALTAVISTA.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Puddin' Man <pudding_man@ALTAVISTA.COM>
Subject:      Re: Can you clear Macrovariables from the PDV during program run?
Comments: To: WHITLOI1@WESTAT.COM
Content-Type: text/plain

> The point is that one can never know in the macro code whether one > has "originally created" or not.

"Never know"? To my knowledge, this is _only_ true when "one" is less than 100% in control of the macros that he/she is running. An example would be when several programmers are working on different, complex, and interdependent macros. There are lots of other examples ...

An example of the converse would be when one develops several simple macros for personal use without any coding help and Understands _Everything_ That Each Macro Does (always recommended).

> In fact in one program the first > call to a macro may be originally creating a local variable and in a > second call (exactly the same) clobbering memory. > > Here is a dangerous example to illustrate the necessity of learning > to use %LOCAL *ALWAYS*. Consider > > %macro mstr ( n = 3 ) ; > %do i = 1 %to &n ; > %slave ( p = 1 ) ; > %end ; > %mend mstr ; > > %macro slave ( p = 1 ) ; > %do i = 1 %to &p ; > %put i=&i ; > %end ; > %mend slave ; > > %mstr () > > As written the code executes until stopped or you run out of some > resource (probably log space). If the call to SLAVE is modified by > setting P = 5 then the program stops prematurely. Thus we have two > 3-line macros which appear to be correctly written except for the > %LOCAL statement, yet the program never works properly. Now imagine > finding the same problem in any realistic program of a realistic > size.

I understand that you are illustrating a point with these 2 macros. I don't really dispute the point: if a single rule is to be followed, then I guess "use %LOCAL *ALWAYS*" makes sense in many, many circumstances (and certainly for the "masses").

But the example above, to po' me, just looks like "bad code" and not an argument for %LOCAL at all. Have a macro, in a loop, call another macro which rewrites the loop counter? Tantamount to suicide! Folks who seriously program in this fashion wind up shooting themselves in the proverbial foot whether they use %LOCAL or not.

And when I write a few simple macros intended to be run only by myself, I'll continue to take the (quite logical) defaults re local/global when appropriate, and use %LOCAL when necessary (and being very, very careful with mac var names, thank you). No doubt this qualifies me for "Eternal Damnation" ... :-)

Puddin'

"People dancin' round a golden calf: those who have none ... and those who have." from "World In Motion", Jackson Browne, maybe 1992

_______________________________________________________________________

Free Unlimited Internet Access! Try it now! http://www.zdnet.com/downloads/altavista/index.html

_______________________________________________________________________


Back to: Top of message | Previous page | Main SAS-L page