Date: Thu, 11 May 2006 19:41:56 +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
In-Reply-To: <7367b4e20605111216v42727635m954289c3349b906a@mail.gmail.com>
Content-Type: text/plain; format=flowed
LOL it has nothing to do with you personally I just dont like that
particular construct....
It violates the principle of simplicity, clarity, flexibiilty and
extendability.
O yeah also it means the problem wasnt properly identified.
In no particular order:
Flexibility because what if the requirements change and I need to now use
both the masked and unmasked value of FOO. I then have to have two macro
vars FOO and FOO2 one with the masked value and one with the unmasked value.
Extendability, well FOO was created in a data step with call symput so lets
say we want to create 50 macro vars from some data set ( this seems like a
more reasonable scenario when one uses call symput). To extend %let Foo =
%bquote( &Foo ) ; we would have to implement another macro var with the
number of macro vars created in the data step and use a %do-Loop. Seems
like it is more trouble than it is worth.
Clarity in that it simply hides the quoting in another step which well
doesnt need to be since we can use the same quoting function in the place in
the code where we need teh quoting performed.
Simplicicty in that it adds more code to write, maintain and remember.
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 15:16:38 -0400
I see, so you object to me using
%let foo = %bquote(&foo);
. . . %upcase(&foo) . . .
in favor of your code
. . . %UPCASE( %bquote( &foo ) ) . .
Is this one of your macro design edicts?
On 5/11/06, toby dunn <tobydunn@hotmail.com> wrote:
>Data _null_ ,
[SNIP]
