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

Ian,

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.

Clint

-----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())


Clinton,

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
t.net>
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()

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