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 (May 2006, week 4)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:   Thu, 25 May 2006 12:27:39 -0500
Reply-To:   Jiann-Shiun Huang <Jiann-Shiun.Huang@AMERUS.COM>
Sender:   "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:   Jiann-Shiun Huang <Jiann-Shiun.Huang@AMERUS.COM>
Subject:   Re: Understanding macro quoting (WAS: enterprise guide peculiarities - %str())
Comments:   To: Hans Schneider <hschneider@CMEDRESEARCH.COM>
Content-Type:   text/plain; charset=US-ASCII

Hans:

A few days back Arthur Tabachneck provided the following link:

http://xrl.us/mpdp

I went through the lecture and found it is useful for beginner although it is for old SAS version. I began to learn SCL several weeks back and found it is a promising tool. If you have Object Oriented Programming concept, with base SAS it will be a powerful tool.

J S Huang 1-515-557-3987 fax 1-515-557-2422

>>> Hans Schneider <hschneider@CMEDRESEARCH.COM> 05/25/06 12:19 PM >>> All,

I never learned SCL. What sources do you recommend to dive into it ?

Hans

-----Original Message----- From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of Rickards, Clinton (GE Consumer Finance) Sent: 25 May 2006 17:18 To: SAS-L@LISTSERV.UGA.EDU Subject: Re: Understanding macro quoting (WAS: enterprise guide peculiarities - %str())

Joe,

To answer your question: Why would anyone in their right mind continue using the antiquated Macro Language when a far superior language is readily available?

A few possibilities from someone who is in their right mind (although my family sometimes has their doubts): 1. It's what they know 2. It works 3. They don't have access to SCL 4. Don't have to manage (store) separate SCL objects (i.e. in a catalog) 5. It's already been written

A few comments: 1. With time pressures, getting to know something new can be difficult 2. It works or they find another way to do the job 3. Does everyone with just Base SAS have access to SCL and if so, how? And do versions of SAS have an impact? I know many people that are still using 6.x. 4. Shared macros have to be managed as well but they can also be defined/used in-line 5. Who will pay to rewrite something that works?

I endorse the idea of using new tools and techniques but sometimes it can be difficult or out of one's hands. Other than suggesting to avoid macros entirely (which is untenable), what clarity can you bring to my original question?

Clint, the obviously left-minded...

-----Original Message----- From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU]On Behalf Of Joe Whitehurst Sent: Thursday, May 25, 2006 11:35 AM To: SAS-L@LISTSERV.UGA.EDU Subject: Re: Understanding macro quoting (WAS: enterprise guide peculiarities - %str())

Clinton,

Here are two more facts to consider: 1. SCL can replace all the functionality of the antiquated Macro Language. 2. There are no quoting functions in SCL because they are never needed.

And 1 question:

Why would anyone in their right mind continue using the antiquated Macro Language when a far superior language is readily available?

Joe

On 5/25/06, Rickards, Clinton (GE Consumer Finance) <clinton.rickards@ge.com> wrote: > > Ian, > > Thanks for the note. I understand that %PUTting _all_ or _user_ yields

> different results from %PUTting a single variable (just the way %put > is programmed). > > Conceptually, I understand why quoting is needed: > > 1. special characters (i.e. non-alphabetic and non-digits) have > meaning to the macro sub-system. For example, & is generally used to > denote the begining of a macro variable reference (e.g. &fred), % is > generally used to denote the beginning of a macro call or reference > (e.g. %my_macro), and a comma (,) is used to separate arguments in > macro functions. > > 2. sometimes I, as a programmer, have a different intent for those > characters. For example, I may want to have a macro variable contain > the constant string Chicken&Dumplings and force the macro processor to

> NOT interpret the string &Dumplings as a macro variable reference. > > Where I get totally confused, and I suspect I am not alone, is > understanding the multitude of quoting/unquoting macro functions that > are available and when they should/should not be used. Many of them > seem to be too similar in definition, at least for my level of > understanding. Which is why my macros are generally rudimentary but > get the basic job done. > > Are there any conference proceedings, etc, that I could look at that > might summarize the quoting "problem" and approaches to it? > > Thanks, > > Clint, the "confused" :) > > -----Original Message----- > From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU]On Behalf Of > Ian Whitlock > Sent: Wednesday, May 24, 2006 8:46 PM > To: SAS-L@LISTSERV.UGA.EDU > Subject: Re: enterprise guide peculiarities - %str() > > > Clinton, > > The simple explanation is that > > %put _all_ ; > > doesn't have to write values the way > > %put &var ; > > does. They doesn't even have to be processed by the same code. (Toby > can never say anything in a few short sentences. He needs paragraph > to get started.) > > On the other hand, there's more to it than that. (Under Widows, the > log shows little boxes instead of spaces.) Now try > > %let x = / ; > %let y = %str(/) ; > > proc sql ; > select name > , value format = $hex6. label = "Value in hex" > , ">>>" || put(value,$3.)||"<<<" label = "Printed Value in > corners" > from dictionary.macros > where name in ( "X" , "Y" ) > ; > quit ; > > to see what the boxes or spaces represent. Then ask yourself what > might happen with > > %put %eval("&x"="&y") ; > > (The quotes are needed to hide the slash from %EVAL.) Yup, they are > equal. So why doesn't %EVAL have to tell the truth? Sometimes a lie > is more convenient than the truth. Consider how much work you would > have to do in order to find out that the symbol held by Y is the same > symbol as that held by X, if %EVAL wasn't willing to lie when it comes

> to macro quoting. > > On the other hand, quoting is a mechanism to say the symbol doesn't > have its expected meaning. Quoting isn't suppose to change the value.

> It's suppose to hide the meaning not the value. So maybe it is SQL > that is lying and %EVAL is telling the truth. > > Perhaps the question should be - why did you expect anything to be > easy when entered the world of quoting? Of course it isn't SI, SAS, > or macro that is the problem. It's quoting. Consider "BOSTON" and > BOSTON. They both have the same 6 letters. So how is it that only > one has more than a million people possible? If you still don't > understand than read go "Alice in Wonderland". > > Maybe Toby's explanation wasn't so bad after all. > > In case it isn't clear, none of this has anything to do with EG and > its pecularities. It just happens to be the scene of the crime. > > Ian Whitlock > =============== > > Date: Wed, 24 May 2006 16:14:55 -0400 > Reply-To: "Rickards, Clinton (GE Consumer Finance)" > <clinton.rickards@GE.COM> > Sender: "SAS(r) Discussion" > From: "Rickards, Clinton (GE Consumer Finance)" > <clinton.rickards@GE.COM> > Subject: Re: enterprise guide peculiarities - %str() > Comments: To: toby dunn <tobydunn@hotmail.com> > In-Reply-To: <BAY101-F21464D229780F3923D5410DE980@phx.gbl> > Content-Type: text/plain; charset="iso-8859-1" > > Toby, > > You're right, you wouldn't win any prizes with that explanation but it

> gets the point across. Thanks... > > -----Original Message----- > From: toby dunn [mailto:tobydunn@hotmail.com] > Sent: Wednesday, May 24, 2006 2:27 PM > To: Rickards, Clinton (GE Consumer Finance); SAS-L@LISTSERV.UGA.EDU > Subject: Re: enterprise guide peculiarities - %str() > > > Clinton , > > It gets complicated, well for me to explain in a few short sentences > it does. Think about it like this %str and %nrstr quote the value at > compile time. Which means that the value that is stored in the symbol

> tables is masked. When quoting macro vars values the characters that > are quoted get transformed to a non printable characeter. All %put > _User_ does is a dump from this table to the log. Hence you see the > slashes as blanks (they are still nonprintable characters). The > symbol tables just hold text values and rermember %put _User_ only > asks for a dump of this to the log, not a dump and a full resolution > of the characters in it. The macro quoting and unquoting and > replacing of nonprintable characters for prinitng purposes gets done > outside of the symbol tables. > > > %put &Test3 > > The value from the resolution of test3 is still quoted, so for compile

> and exectution time they are masked from the macro facility, but for > printing purposes SAS will replace the nonprintable chars with the > correct ones. > > This is probably a really bad explaination I will have to work on it > some more. > > Toby Dunn > > > > > > From: "Rickards, Clinton (GE Consumer Finance)" > <clinton.rickards@GE.COM> > Reply-To: "Rickards, Clinton (GE Consumer Finance)" > <clinton.rickards@GE.COM> > To: SAS-L > Subject: Re: enterprise guide peculiarities - %str() > Date: Wed, 24 May 2006 13:48:51 -0400 > > All, > > Interesting... %PUT of the individual variable works but _all_ and > _user_ does not in my environment (EG 3.0 talking to 9.1.3 on > Solaris). Any rational reason why not? > > 11 %let slashes = %str(//test/test2) ; > 12 %let test3 = &slashes./test4 ; > 13 %put %unquote(&slashes); > //test/test2 > 14 %put %unquote(&test3); > //test/test2/test4 > 15 > 16 %put #############; > ############# > 17 %put _ALL_; > GLOBAL _EGUSERID 222016322 > GLOBAL _EGHOSTNAME srapdm01.usc.consfin.ge.com > GLOBAL _CLIENTUSERID 222016322 > GLOBAL _EGUSERNAME 222016322 > GLOBAL _EGSERVERNAME FraudMain > GLOBAL _EGMACHINE MYUSLWSHL203604 > GLOBAL _SASHOSTNAME srapdm01.usc.consfin.ge.com > GLOBAL SLASHES test test2 > GLOBAL _CLIENTAPP SAS Enterprise Guide > GLOBAL TEST3 test test2 /test4 > GLOBAL _CLIENTUSERNAME 222016322 > <snip> > 18 > 19 %put #############; > ############# > 20 %put _user_; > GLOBAL _EGUSERID 222016322 > GLOBAL _EGHOSTNAME srapdm01.usc.consfin.ge.com > GLOBAL _CLIENTUSERID 222016322 > GLOBAL _EGUSERNAME 222016322 > GLOBAL _EGSERVERNAME FraudMain > GLOBAL _EGMACHINE MYUSLWSHL203604 > GLOBAL _SASHOSTNAME srapdm01.usc.consfin.ge.com > GLOBAL SLASHES test test2 > GLOBAL _CLIENTAPP SAS Enterprise Guide > GLOBAL TEST3 test test2 /test4 > GLOBAL _CLIENTUSERNAME 222016322 > > -----Original Message----- > From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU]On Behalf Of > toby dunn > Sent: Wednesday, May 24, 2006 1:34 PM > To: SAS-L > Subject: Re: enterprise guide peculiarities - %str() > > > Jiann , > > When you reference a the macros in a %put statement they dont need to > be > unquoted: > > 77 %let slashes = %str(//test/test2) ; > 278 %let test3 = &slashes./test4 ; > 279 > 280 %put &test3 ; > //test/test2/test4 > 281 %put &Slashes ; > //test/test2 > > > > Toby Dunn > > > > > > From: Jiann-Shiun Huang <Jiann-Shiun.Huang@AMERUS.COM> > Reply-To: Jiann-Shiun Huang <Jiann-Shiun.Huang@AMERUS.COM> > To: SAS-L > Subject: Re: enterprise guide peculiarities - %str() > Date: Wed, 24 May 2006 12:02:56 -0500 > > Hans: > > Use %unquote to restore the significance of symbols as the > following shows. > > 60 %let slashes = %str(//test/test2) ; > 61 %let test3 = &slashes./test4 ; > 62 %put %unquote(&slashes); > //test/test2 > 63 %put %unquote(&test3); > //test/test2/test4 > > > J S Huang > 1-515-557-3987 > fax 1-515-557-2422 > > >>> Hans Schneider <hschneider@CMEDRESEARCH.COM> 05/24/06 11:44 AM >>> > Dear Listeners, > > I stumbled over an irritating macro var resolution, using EG: > > %let slashes = %str(//test/test2) ; > %let test3 = &slashes./test4 ; > > %put _all_ ; > GLOBAL SLASHES test test2 > GLOBAL TEST3 test test2 /test4 > > Slashes are not correctly reproduced (and brackets as well ?), when > the string is enclosed in %str()... > > ...strange... > > Any ideas ? > > Cheers, > > Hans >

_____________________________________________________________________ This e-mail has been scanned for viruses by Verizon Business Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.mci.com


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