Jack is quite correct -- since the DATA step variables to be created need to
be known at compile time, my proposal to rely on the names in the parsed
value (which could of course be an expression) would not work.
I'm not sure I understand the point about eliminating the RX variables --
since there may be more than one pattern active at a time, seems to me that
the programmer needs some way to tell SAS which pattern to use. (There was
a bug in the v6 implementations that prevented the use of multiple patterns
simultaneously, but I'm pretty sure that has been fixed.)
From: Jack Hamilton [mailto:JackHamilton@FIRSTHEALTH.COM]
Sent: Thursday, August 02, 2001 6:00 PM
Subject: Re: RXPARSE, RXMATCH : storing pattern matches in sas variables
What I would suggest is changing the way the function is called. Instead of
having 4 arguments, RXCHANGE could have 4 or more arguments. When called
with 4 arguments, it would perform exactly as it does now.
The additional arguments would be string variables, one for each value you
An earlier example used
if _n_ = 1 then do;
* the =n in the TO is the nth un-named tagged match expression;
rx = rxParse ("first=<:?>.<:?>'@'<:?>.:? TO =first','=1','=2");
call rxChange (rx, 999, addr, normalized);
first = scan (normalized,1,',');
last = scan (normalized,2,',');
comp = scan (normalized,3,',');
My suggest would replace the second section of code with
call rxChange (rx, 999, addr, normalized, first, last);
I think this is easier to understand. I would think it would easier to
implement as well, since it wouldn't require the supervisor to parse the
rxparse string for variable names.
Come to think if, I don't understand how the suggestion below could possibly
work - the rxparse string might not have been available to the supervisor at
run time, and consequently it couldn't be parsed for variable names.
What I would really like is the elimination of the rx variable - the SAS
supervisor should keep track of that kind of internal information, just as
it does with the LAG function. That could be implemented without breaking
any existing uses of the regular expression functions.
Development Manager, Technical Group
METRICS Department, First Health
West Sacramento, California USA