Date: Tue, 13 Nov 2001 08:18:12 -0500
Reply-To: "Diskin, Dennis" <Dennis.Diskin@PHARMA.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: "Diskin, Dennis" <Dennis.Diskin@PHARMA.COM>
Subject: Re: SAS array and output
Content-Type: text/plain; charset="iso-8859-1"
Paul,
The distinction of "executable" vs. "non-executable" is a long standing one
in programming literature, going back at least to early FORTRAN
documentation. You can always quibble about terminology if you don't like
common usage. English is great for terms such as "near miss" which some
people spend large amounts of time discussing.
Dennis Diskin
> -----Original Message-----
> From: Dorfman, Paul [SMTP:Paul.Dorfman@bcbsfl.com]
> Sent: Monday, November 12, 2001 6:19 PM
> To: 'Diskin, Dennis'; SAS-L@LISTSERV.UGA.EDU
> Subject: RE: SAS array and output
>
> Dennis Diskin, in part, wrote:
>
> > In SAS (as well as many other languages), many non-executable
> > statements can be placed anywhere in the program with the same effect.
>
> Concurring that there exist statements having the same effect regardless
> of
> their location in the code (not many - see below), I disagree - and not at
> all purely semantically - with the way the term 'non-executable' has been
> used when it comes to this topic. The only non-executable statements are
> those commented out or ones the programmer has not coded. As such, they
> are
> completely ignored by the compiler without any attempt to interpet their
> meanings. All other statements are executed by the software, only at
> different times and different number of times. Thus instead of talking
> about
> executable and non-executable instructions, we should talk about ones
> executed at the compile time and run time. This is also important from the
> pedagogical perspective, since it does not create the wrong impression
> that
> if a statement is 'non-executable', it can be dealt with without the same
> sense of import given to 'executable' statements. In fact, the
> compile-time
> directives are every bit as important as run-time directives, often
> affecting performance to the same, if not greater, extent.
>
> I do realize that the term stems from the SAS documentation, but this is
> not
> the only confusing think coming from the manual (just look, for the sake
> of
> fun, at the definition of the RETURN statment).
>
> > You could think of it as taking all the non-executables and grouping
> them
> > together at the beginning.
>
> That who views all statements as executable would perhaps abstain from
> such
> a practice. The DKR and LABEL are the only compile-time directives I can
> think of that have absolutely the same effect regardless of their location
> in the DATA step. Just about everything else from that realm - RETAIN,
> LENGTH, and especially ARRAY may have profoundly different effect
> depending
> on their location with respect to other - both compile and run time -
> instructions.
>
> > In fact, this is recommended or required (for clarity and ease of
> reading)
> > by many coding standards I have encountered.
>
> I have seen a recommended SAS coding standard once, and have never seen a
> required one, let alone many. If I were required to adhere to the standard
> telling me in which sequence I must code SAS statements, my services would
> not be required, because determining such a sequence is precisely what
> SAS
> programmers do. Recommendations are OK (unless they are mandatory), but
> rigid coding standards such as ones encountered in COBOL shops, are
> counterproductive. As far as the provision to group all 'non-executable'
> statements before all executable ones goes, it hardly makes sense, for
> even
> though it might make a program 'clear' and 'readable', it can very well
> render it inoperative. For instance, one could replace missing values with
> zeroes as in
>
> data b ;
> set a ;
> array aa _numeric_ ;
> do over aa ;
> if aa = . then aa = 0 ;
> end ;
> run ;
>
> but think what would happen if the programmer, in his zeal of adhering to
> the letter of the 'required' shop standard, made the 'non-executable'
> array
> the first statement of the step.
>
> Kind regards,
> ====================
> Paul M. Dorfman
> Jacksonville, FL
> ====================
>
>
> Blue Cross Blue Shield of Florida, Inc., and its subsidiary and
> affiliate companies are not responsible for errors or omissions in this
> e-mail message. Any personal comments made in this e-mail do not reflect
> the views of Blue Cross Blue Shield of Florida, Inc.
>
| 
