Date: Tue, 25 Mar 2008 11:21:22 -0500
Reply-To: "data _null_," <datanull@GMAIL.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: "data _null_," <datanull@GMAIL.COM>
Subject: Re: if 0 then set data ...
In-Reply-To: <200803251537.m2PAmAnO019936@malibu.cc.uga.edu>
Content-Type: text/plain; charset=ISO-8859-1
This example is completely contrived but it does show how attributes
can be copied from a data set to create new variables. I used to use
a similar technique back when we had to read procedure output that had
been saved to a file with PRINTTO. It was particularly useful reading
BYLINES where you wanted the by variable(s) to have the proper
attributes, and you wanted the code to be somewhat dynamic.
filename FT16F001 temp lrecl=256;
%let data=sashelp.shoes;
data _null_;
file FT16F001;
set &data;
put (_all_)(=);
run;
data work.class;
if 0 then set &data;
infile FT16F001;
input (_all_)(=);
run;
proc contents varnum;
proc print;
run;
On Tue, Mar 25, 2008 at 10:37 AM, Chang Chung <chang_y_chung@hotmail.com> wrote:
> On Tue, 25 Mar 2008 05:08:41 -0400, Gerhard Hellriegel
> <gerhard.hellriegel@T-ONLINE.DE> wrote:
>
> >If you look at the following example, you see that SET has two meanings.
> >
> >data a;
> > put n=;
> > put age=;
> > set sashelp.class nobs=n;
> >run;
> >
> >First is the global: open the dataset, read the header to get all
> >structure information. Second is to build the PDV and read all obs in a
> >automatic loop. You can also say: SET is both, executable and not. The not-
> >executed SET gives information about the dataset to the compiler, the
> >second is executed (obs are read and written in a loop).
> >Look at the first output: N (number of obs) is available, the "global" SET
> >has done his work. The "local" SET has not: AGE is still missing, no obs
> >has been read.
> ...
>
> hi,
>
> the documentation says that there are two kinds of statements in the data
> step: executable and declarative. Executable statements are executed during
> the execution time; Declarative statements provide the compiler some
> information during the compile time.
>
> Notice that si was careful and did *not* say that executable statements do
> not help compiler. Because some of them do. One of them is the set
> statement, which is executable, but does give compiler the data set header
> information (variable names, their order, types, number of observations and
> so on).
>
> so the ugly hack, "if 0 then set ds" works since the "set ds" gives the
> header information of the data file ds to the compiler (and then the
> compiler which does not know that it is not to be executed sets up the pdv
> accordingly), but is skipped in the execution time because the if condition
> is false.
>
> i say it is "ugly" since it takes advantage of and thus exposes of the
> spectacularly messy identity of the data step language, which was invented
> as a declarative (a 4th gen programming) language, but has been evolved to
> include more and more procedural elements into it. For those who are used
> to, it is a fantastically rich and often a very succinct but expressive
> language. For those who just started learning, it is one of the difficult
> languages to speak fluently. It is mainly because the language itself
> suffers from the multiple identity syndrome.
>
> Maybe this is more confusing. Well, everybody has different learning style
> and maybe for some, this maybe a bit easier, i hope. :-)
>
> cheers,
> chagn
>
| 
