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 2)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:         Thu, 11 May 2006 18:47:33 +0000
Reply-To:     toby dunn <tobydunn@HOTMAIL.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         toby dunn <tobydunn@HOTMAIL.COM>
Subject:      Re: UPCASE and unmatched parenthesis conundrum
Comments: To: datanull@GMAIL.COM
In-Reply-To:  <7367b4e20605110951g52516c89kb01af3e8de3019eb@mail.gmail.com>
Content-Type: text/plain; format=flowed

Data _null_ ,

I never said %str() would not provide a solution, it just doesnt provide the solution to the problem as I see it.

I said that "The problem to be solved is not how to mask the unmatched parenthesis at assignment but rather when the macro variable is used." A %let statement as well as the call symput and call execute would accept the single paren with no problems nor complaints. So macro compile time isnt the problem, the problem is at macro execution time specifically with the resolved value. And %str and %nrstr are macro compile time masking functions while the rest are macro execute time masking functions.

For example this wont work:

%macro foo; data _null_; call symput ('foo', 'The unusual case of (the unmatched parenthesis'); run;

%put foo=&foo;

%put upcase foo = %UPCASE(%str(&foo));

data ugg; foo = 0; LABEL foo = "%UPCASE(%str(&foo))"; run; %mend;

options mprint;

%foo;

But this will:

%macro foo; data _null_; call symput ('foo', 'The unusual case of (the unmatched parenthesis'); run;

%put foo=&foo;

%put upcase foo = %UPCASE(%bquote(&foo));

data ugg; foo = 0; LABEL foo = "%UPCASE(%bquote(&foo))"; run; %mend;

options mprint;

%foo;

Now by point of use I am refering to:

%UPCASE( %bquote( &foo ) ) in the example above. The macros value isnt masked until it is needed. No intermediate step of creating another macro variable whos value conatins the resolved value of 'FOO' that is masked.

By extra over head, think of the example expanded out to create say 50 macro vars via the data null and call symput step, where you have no idea if the values will have or not have a single paren. Now you have to add a %do loop to create 50 more macro vars (up to a hundred macro vars now). If one was to use the %bquote method at the point of macro var FOO's usage you would only need the first set of 50 macro vars. And to top all of this off you cant use the %str or %nrstr in this way without hard coding a %str() around the paren and prefixing the paren with a '%'. So even if one wanted to use a compile quoting function they would have to preprocess the data first before feeding it too the symput.

I think you get where the complexity comes in at by now so I belabor the point .

Toby Dunn

From: "data _null_;" <datanull@GMAIL.COM> Reply-To: "data _null_;" <datanull@GMAIL.COM> To: SAS-L@LISTSERV.UGA.EDU Subject: Re: UPCASE and unmatched parenthesis conundrum Date: Thu, 11 May 2006 12:51:29 -0400

I don't really understand your point. On the one hand you say that %STR wont work in this situation but it you look at Venky's solution you can see that using %STR will work.

My use of the term "blind quote" is derived from my, perhaps mistaken, notion that the B in BQUOTE stands for blind.

I think my solution does use "point of use" quoting. So please explain the difference. Especially all that overhead and complexity part.

On 5/11/06, toby dunn <tobydunn@hotmail.com> wrote: >I am only going to half way agree here. > > >Seems to me that the point here is NOT, how to mask an unmatched > >parenthesis, when the macro variable value is assigned using %STR or > >%NRSTR, but how to mask it when the macro variable has been assigned > >by some other means CALL SYMPUT or SQL perhaps. > > >I would rephrase it to : > >The problem to be solved is not how to mask the unmatched parenthesis at >assignment but rather when the macro variable is used. Therefore, compile >time macro quoting functions do not solve the problem and one needs to use >execution time macro quoting functions to mask the resolved value of macro >variable of question. > >So the question then becomes which method is better in terms of macro >design. > >A blind quoting as Data _null_ suggested or using a execution time macro >quoting function at the point of usage. Nothing against you there Data >_null_ I just dont like blind quoting anything. I prefer point of usage >quoting since it places the quoting function in context thus increasing the >clarity of the code IHMO. Also it silves the problem of when you need both >the quoted resolved value and the unquoted resolved value in a program. >Blind quoting increases the not only the overhead to write and mainatin but >also increases the complexity of the code. > > > > >Toby Dunn > > > > > >From: Venky Chakravarthy <swovcc@HOTMAIL.COM> >Reply-To: Venky Chakravarthy <swovcc@HOTMAIL.COM> >To: SAS-L@LISTSERV.UGA.EDU >Subject: Re: UPCASE and unmatched parenthesis conundrum >Date: Thu, 11 May 2006 11:57:33 -0400 > >On Thu, 11 May 2006 10:42:55 -0400, data _null_; <datanull@GMAIL.COM> >wrote: > > >Seems to me that the point here is NOT, how to mask an unmatched > >parenthesis, when the macro variable value is assigned using %STR or > >%NRSTR, but how to mask it when the macro variable has been assigned > >by some other means CALL SYMPUT or SQL perhaps. > >I agree. That is the reason I mentioned: ><<<<<<<<<< > >> That said this may not be an ideal solution as you are probably >grabbing > >> whatever is available to you to assign to FOO. In that case one of the > >> other solutions offered may be more desirable. > >>>>>>>>>> > > > > >Therefore seems that BQUOTE NRBQUOTE or SUPERQ, would be the solution of >choice. > >Again, I concur. > > > > > > > > >On 5/11/06, Venky Chakravarthy <swovcc@hotmail.com> wrote: > >> On Wed, 10 May 2006 23:48:29 -0400, Richard A. DeVenezia > >> <rdevenezia@WILDBLUE.NET> wrote: > >> > >> >This code fails 'miserably'. The expected label statement is not > >> generated. > >> >Instead the session is left is some sort of 'open' state at the LABEL > >> >statement . Any ideas why and how to correct? > >> > > >> >%macro foo; > >> > data _null_; > >> > call symput ('foo', 'The unusual case of (the unmatched >parenthesis'); > >> > run; > >> > > >> > %put foo=&foo; > >> > > >> > %put upcase foo = %UPCASE(&foo); > >> > > >> > data ugg; > >> > foo = 0; > >> > LABEL foo = "%UPCASE(&foo)"; > >> > run; > >> >%mend; > >> > > >> >options mprint; > >> > > >> >%foo; > >> > > >> >-- > >> >Richard A. DeVenezia > >> >http://www.devenezia.com/ > >> > >> > >> As per the documentation %str and %nrstr are both capable of masking > >> unmatched parenthesis if preceded by a %. Thus changing > >> > >> > call symput ('foo', 'The unusual case of (the unmatched >parenthesis'); > >> > >> to > >> > >> > call symput ('foo', 'The unusual case of %str(%()the unmatched > >> parenthesis'); > >> > >> worked for me. > >> > >> That said this may not be an ideal solution as you are probably >grabbing > >> whatever is available to you to assign to FOO. In that case one of the > >> other solutions offered may be more desirable. > >> > >> Venky Chakravarthy > >> >


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