Date: Tue, 20 May 1997 11:37:31 -0700
Reply-To: Karsten Self <kmself@PMSQUARED.COM>
Sender: "SAS(r) Discussion" <SAS-L@UGA.CC.UGA.EDU>
From: Karsten Self <kmself@PMSQUARED.COM>
Subject: Re: SUGGESTION: Data step code in formats
Content-Type: text/plain; charset="us-ascii"
As I see this, Jack is asking for the ability to write user-defined
functions. The only current modes for doing this are:
SAS Toolkit: you can do whatever you want and destroy memory in the
process, C and $ required
Proc FORMAT: table-lookup substitutions and some simple modifications
Macro: with creative programming, some moderately complex expressions
can be defined to be used similarly to SAS functions in Data step, SQL,
and SCL. Method is limited by ability to represent logic and functions
in a single expression with no step boundaries (no ';' in macro).
Limited error handling capabilities. Very obscure code can result.
Macro resolution (MPRINT) can be really fun to pick apart.
I recall rumors that user definable functions are being considered as an
addition to SAS in an upcoming release (the answer to Life, the
Universe, and Everything is now '7'), not sure what current status of
this is, it's certainly something that's been requested over the years.
I see four general forms of such a function, the first three of which
would be most preferred:
- Simple table lookup: equivalent to today's Proc FORMAT. Argument is
replaced by value.
- Multidimensional table lookup: similar to a Proc FORMAT, but
assignment is based on multiple input arguments. This would normally be
accomplished presently by a multidimensional array lookup.
- Function: full-fledged function specification, including error
handling, conditional and flow-of-control, resulting in a single output
- Call Routine: similar to above, but resulting in multiple output
values or producing something other than a value. This would be similar
to existing SAS CALL routines, which may change environment (SYMPUT,
LABEL, VNAME), generate program statements (EXECUTE), execute system
commands (SYSTEM), or alter the values of multiple variables (random
A current problem of mine involves generating a value based on
accounting practice definitions, which may or may not have any inherent
logic in them -- the result might be based on functional manipulations
of values, or on a lookup table. Though Macro may offer a solution,
being able to code this as a function would be much preferred.
>From: Jack Hamilton[SMTP:Jack_Hamilton@HCCOMPARE.COM]
>Sent: Monday, May 19, 1997 2:12 PM
>To: Multiple recipients of list SAS-L
>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:
> proc codedformat;
> 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