|Date: ||Tue, 20 May 1997 09:18:25 -0500|
|Reply-To: ||Andrew Kowalczyk <Andrew.Kowalczyk@ANIXTER.COM>|
|Sender: ||"SAS(r) Discussion" <SAS-L@UGA.CC.UGA.EDU>|
|From: ||Andrew Kowalczyk <Andrew.Kowalczyk@ANIXTER.COM>|
|Subject: ||SUGGESTION: Data step code in formats|
SASware Ballot's are due June 2, 1997. You can e-mail them to SUGGEST@SAS.COM
Date: Mon, 19 May 1997 13:12:28 -0800
From: Jack Hamilton <Jack_Hamilton@HCCOMPARE.COM>
Subject: SUGGESTION: Data step code in formats
I would like to be able to write formats which use data step code.
Someone wants to read a date or time in a non-standard format. How to
do this is one of the most frequently asked questions on SAS-L. There
are a bazillion date formats, and SAS will never be able to provide
them all. Someone will always come up with an obscure but legitimate
way to enter times and times (old-style Dutch vm/nm times, or mdy
separated with backslashes instead of forward slashes, for example).
There are workarounds, but they all look terrible; they usually involve
reading the date as a string, breaking it apart, and running it through
various string and date functions. The code becomes more complicated,
and the purpose of the code becomes obscured.
Just today, someone wanted to read numbers with trailing minus signs,
for which there is no SAS informat.
SAS could have a syntax like this:
invalue nlvmnm. (invalue=invalue outvalue=outvalue);
newvalue = upcase(invalue);
if index(newvalue, "VM") > 0 then
newvalue = tranwrd(newvalue, "VM", "AM");
newvalue = tranwrd(newvalue, "NM", "PM");
outvalue = input(newvalue, time.);
invalue trailmin. (invalue=invalue outvalue=outvalue
if substr(invalue, inlength, 1) = "-" then
outvalue = input(invalue, best.) * -1;
outvalue = input(invalue, best.);
The syntax (and semantics) obviously need to be improved. There would
need to be a way to handle errors, and a better way to pass modified
values to a built-in (or user-written) function for further handling.
It might be useful to be able to pass it a parameter (as with the
built-in format $VARYING.), and it would probably be nice to be able to
get the characteristics of the variable the format is being applied to.
There's probably a ton of additional stuff I haven't thought of, but I
think the underlying idea is a good one.
You could probably use a simlar syntax to allow user-written functions,
which would also be useful.
If you implement something like this, please store the original code
along with the compiled code, so the resulting formats can be moved
between systems and releases. I think it was a mistake to make
compiled data steps non-transferable.
HealthCare COMPARE Corp.
West Sacramento, CA