Date: Tue, 25 Mar 2008 09:59:20 -0700
Reply-To: Jack Hamilton <jfh@STANFORDALUMNI.ORG>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Jack Hamilton <jfh@STANFORDALUMNI.ORG>
Subject: Re: Table-driven programming WAS: Scope of macro variable using
Content-Type: text/plain; charset="iso-8859-1"
I see a difference between data (or table) driven and metadata driven. I would call a program data driven if it assumes a particular structure in its input, and uses the values in a table to decide what to do. I would call it metadata driven if it has to investigate the properties of its input data sets before deciding what to do (at which poiint it might become a data driven program.
There's not always a clear line, of course.
From: Alan Churchill <savian001@GMAIL.COM>
Sent: Tuesday, March 25, 2008 9:14 AM
Subject: Re: [SAS-L] Table-driven programming WAS: Scope of macro variable using "call symput"
I would amend your "table-driven programming" to "metadata driven
I have built UIs that were completely driven by SQL Server tables and SAS
datasets (buttons, tabs, tree structures, etc. were dynamic and changed
according to what was in the table). I also do a lot of work using XML which
is hierarchical and much better suited to a lot of tasks. XML is also much
more flexible than row/columns and is increasingly used vs. table-driven.
From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of Mary
Sent: Tuesday, March 25, 2008 8:28 AM
Subject: Table-driven programming WAS: Scope of macro variable using "call
Actually, I do find what data_null is saying here to be very wise advice,
and actually in the direction that software engineering has taken a hold of
lately, the concept of "table-driven programming".
In working at the hospital, we saw that the large companies involved in
producing medical records software (IDX, EPIC), very much used the concept
of "table-driven programming" in their designs, in that database tables
could be used to a great extent over using individual variables or hard
coding of data, and thus the code would not have to be tailored for a
different client but rather the contents of the tables for each client could
This made a lot of sense to me, since I had been a statistical programmer.
SAS is a natural language to implement this idea, since it focuses around
the data set. It did strike me as a bit odd when I first joined the list as
to how much was being done in macros that could have been done in data
steps; to me, macros were primarily useful in reducing repetitive code by
passing parameters, but not as a substitute for SAS's rich data step
language (but then, I'm a statistical programmer and my SAS applications may
be different than that of a non-statistical SAS programmer).
Thus, data_null's idea of relying on data steps, and using data sets where
possible rather than macro variables, makes a lot of sense to me, and
actually seems to be more consistent with the "table-driven" programming
concepts that seem to be taking hold in the software industry.
----- Original Message -----
From: data _null_,
Sent: Monday, March 24, 2008 6:40 PM
Subject: Re: Scope of macro variable using "call symput"
I don't claim to know anything I am a student of SAS programming. I
still say that it is pointless to process all variables in a data set
into macro variables
I don't have a web page with examples of macros like you have. Nor do
I have web page of the kind of programs that I do write. There are a
few examples on SAS-L of the kinds of programs write. I like to write
stand alone (self contained) programs that use data and proc steps to
accomplish tasks. For some time I had tried to use the approach you
seem to prefer where every little task is canned into a macro but I
found it too burdensome to keep track of it all. Instead of writing
more macros I decide to try to learn to write better SAS programs,
using traditional SAS code, and macro language where appropriate.
It seems that for many programmers they are using macros in a grand
battle to tame SAS and have it succumb to their will. I used to be
one of them. But if you take a different approach and let SAS help
you then most things that seem difficult become much easier.
I can't answer that. I read almost everything that is posted to
SAS-L. I find it all fascinating.
It still seems to me that given a data set as you describe for the
purpose you suggest you could do a lot better sticking with data step
language or procs to drive the application. Sure you may need or want
to make some macro variables but if you keep the data in a data set
longer you are able to make processing them much easier. To better
understand your application I ask. Once you put all the variables from
the data set into macro variables what did you do next? Could any or
all of that been done more easily using data step language?