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:         Fri, 26 May 2006 07:35:56 -0400
Reply-To:     "Rickards, Clinton (GE Consumer Finance)"
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         "Rickards, Clinton (GE Consumer Finance)"
Subject:      Re: Understanding macro quoting (WAS: enterprise guide
              peculiarities              - %str())
Comments: To: iw1junk@COMCAST.NET
In-Reply-To:  A<>
Content-Type: text/plain; charset="iso-8859-1"


Thanks for all your help over the years to those of us who struggle with macros. I am beginning to see a glimmer of understanding, which I hope will stay with me as I write my next piece of macro code. To whit: Internally, macro may embed a symbols with hidden quotes which are not part of the value of the symbol but allow SAS to treat that symbol differently than the norm. The trick is understanding how and when the internal, hidden quoting is done and interpreted.

Although I subscribe to the philosophy of copying the masters (i.e. you) if you can't do your own, I'd much rather be able to do my own.


-----Original Message----- From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU]On Behalf Of Ian Whitlock Sent: Thursday, May 25, 2006 5:36 PM To: SAS-L@LISTSERV.UGA.EDU Subject: Understanding macro quoting (WAS: enterprise guide peculiarities - %str())


I suspect that the SI developer did not fully appreciate quoting problems when developing the macro language.

Personally I use three quoting functions at the most.

1) %STR(<symbol>)

Works at compile time and keeps meaning hidden through execution unless certain functions are applied. Can only be used when person typing the code also types the symbol that needs hiding. As a rough estimate it accounts for 80% of my usage.

2) %SUPERQ(<variable name>)

Symbols are sometimes not a problem when typed but become a problem when evaluated. For example,

%let list = a, b, c ; %put %scan(%superq(list), 2) ;

Note the name, LIST, not the reference &LIST is used with %SUPERQ. %SUPERQ will expect any macro expression to resolve into a variable name.

3) %NRSTR(<symbol>)

On rare occasions it is needed to hide a %-sign

Most of the time the culprit you are trying to hide symbols from is %EVAL. Remember %EVAL is implictly invoked whenever an arithmetic expression is expected. A large percentage of the quoting problems arise from the use of macro quoting when none is needed.

One note on the message below. I forgot to add the oddity that it is possible for &X to equal to &Y while %LENGTH(&X) is not equal to %LENGTH(&Y). Consequently a true test for equality must include testing the lengths if spaces are important.

%let x = q ; %let y = %str( q ) ; %put %eval(&x=&y) ; %put %eval(%length(&x)=%length(&y)) ;

Oh yes, on the question of %PUT behavior. The only way a table dump can show quoting is to expose the quoting strategy. With a simple %PUT one is probably not interested in seeing that.

Ian Whitlock ================= Date: Thu, 25 May 2006 11:03:46 -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: Understanding macro quoting (WAS: enterprise guide peculiarities - %str()) Comments: To: iw1junk@COMCAST.NET In-Reply-To: A<052520060045.8257.4474FE3D00080F2700002041220922992705029A06CE9907@comcas> Content-Type: text/plain; charset="iso-8859-1" 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 Subject: Re: enterprise guide peculiarities - %str()


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 =============== <snip>

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