Date: Tue, 8 Feb 2005 15:06:34 +0000
Reply-To: iw1junk@COMCAST.NET
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Ian Whitlock <iw1junk@COMCAST.NET>
Subject: Re: Bug in %SCAN (was Re: %substrw)
Toby,
The documentation is pretty clear that quote marks are both tokens
and have a quoting ability. Would you really want to change the
rules for %PUT? Consider
%put "Toby; what's wrong with this statement?" ;
%put 'What about %mac?' ;
Answer, by your rules, the semi-colon is no longer inside a quote
and the macro %MAC would execute.
Now what if the %PUT were replaced by %LET X=? Would you want the quote mark rules changed here also?
The treatment of quote marks in the macro language does cause little
hang-ups, especially in off the track code; but for the most part for
daily programming usage the Institute decision was a wise one.
I do wish that the error message had indicated that it came from %PUT,
but even that desire is probably too much. I suspect that the message came
from a routine that did not even know it was handling tokens for %PUT.
If time is to be spent, I would much rather have a smart DATA step SCAN function with parameters to say "don't look inside quoted expressions", "don't look inside paired parentheses", "treat consecutive delimiters as indicating a missing or empty value", etc. Which then should be ported to the macro language or at least operate with %SYSFUNC etc.
Ian Whitlock
========================
Date: Tue, 8 Feb 2005 14:06:21 +0000
Reply-To: toby dunn <tobydunn@HOTMAIL.COM>
Sender: "SAS(r) Discussion"
From: toby dunn <tobydunn@HOTMAIL.COM>
Subject: Re: Bug in %SCAN (was Re: %substrw)
Comments: To: radevenz@IX.NETCOM.COM
In-Reply-To: <36qmtcF3bqn09U1@individual.net>
Content-Type: text/plain; format=flowed
Richard,
I am going with a bug and poor error message...
%put shouldn't act exactly like a PUT statement in as much as the
underlying
differences between SAS code where words have meanings and in macro land
where the user tells the SAS macro facility what has meaning by using
tolkiens. Thus, I would sermise that when using a %put statement there
needn't be a problem when using one quote or two qoutes, it should be just
text. The only way I can see a possible problem is if the %eval statement
is either called implicitly or explicitly in the %put statement where it
might need balanced quotes to function properly. Even then I would expect
a
better error message than open code recursion.
Toby Dunn
From: "Richard A. DeVenezia" <radevenz@IX.NETCOM.COM>
Reply-To: "Richard A. DeVenezia" <radevenz@IX.NETCOM.COM>
To: SAS-L
Subject: Re: Bug in %SCAN (was Re: %substrw)
Date: Mon, 7 Feb 2005 21:36:05 -0500
Ian Whitlock wrote:
> 4 ODS LISTING;
> 5 %put ===========================;
> ===========================
> ERROR: Open code statement recursion detected.
> 6 %put %scan ( a "b c", 2 , %str( )) ;
> 7 %put ===========================;
> 8 run;
> 9 quit;
> 10
>
> Anyone have any idea where the recursion is coming from? I get the
> same
> result in version 9.1.2 with macro quoting by %SUPERQ. Although SCAN
> works as expected, you cannot cheat and use
>
> %SYSFUNC(SCAN( a "b c", 2 , %str( )))
>
> since it has the same recursion problem. However SCAN in a DATA step
> works as expected yielding "b.
>
> Ian Whitlock
I believe this falls in the realm of usage note and not bug.
I am guessing the %scan properly extracts the "b, but does not encapsulate
the result for %put. qscan works properly because the macro value obtained
by thing scanning process is macro quoted.
The equivalent error is obtained by a simple
%put "b;
The quoted string is unterminated and leads to a 'dead line' in the log and
leads to obvious confusions.
Consider this example in a new session.
1 %put "b;
2 %put;
ERROR: Open code statement recursion detected.
3
4 data _null_;
5 run;";
"b;data _null_;run;"
6
7 data _null_;
8 run;
NOTE: DATA statement used (Total process time):
real time 0.00 seconds
cpu time 0.00 seconds
The
"b;data _null_;run;"
is the result of the initial %put whose dquoted value is 'closed' by the
dquote after the run;
The recursion complaint is no doubt the second %put while the first %put
had
yet to find the closing dquote it wanted.
I see the same in both v9 and v8
--
Richard A. DeVenezia
http://www.devenezia.com/
