Date: Thu, 6 May 2004 02:28:21 -0400
Reply-To: Richard Ristow <wrristow@MINDSPRING.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Richard Ristow <wrristow@MINDSPRING.COM>
Subject: Re: macro
Content-Type: text/plain; charset="us-ascii"; format=flowed
At 08:36 PM 4/29/2004, David L. Cassell wrote:
>pudding man <pudding_man@MAIL.COM> sagely said (Thu, 29 Apr 2004
>>I'm not strongly inclined to disagree with Jack, Ian, or David on
>>this point[, and accept that the SAS macro language is a programming
>>language], but ...
>>Isn't there a potentially very important adjective that has been
>>missing from the discussion. Could such adjective be spelled R-o-b-u-s-t? :-)
>Robustness is certainly a reasonable concern. However you define it.
>[...] The SAS macro language is certainly more flexible and useful and
>feature-full than a lot of 'official programming languages'. [...] So,
>on some mythical 'robustness' score, I would give the SAS macro
>language a mediocre but still decent score, way above a lot of
>languages [...] in which real programmers actually program. For money.
That last is fair enough -- I've written JCL for money! (It sure wasn't
Is the macro language a "programming language"? How many logic
statements can dance on the head of a pin? I'd say it easily meets the
hypotheses of Turing's Universality Theorem, or similar results,
meaning it has in principle all the power of any programming language.
(This is not a high test to pass. In fact, one of Turing's key insights
was, how little complexity a computing system needs, in order to have
the power to perform any computation.) I don't suppose one would
normally write, say, a chess-playing program, or a regression routine,
in the macro language, but that's mainly because you'd be hamstringing
the macro language: using none of its specific strengths.
But 'robust'? Flexible and feature-full are fine, but I'd say a
'robust' language helps, or at least does not hinder, writing clear
programs. The SAS macro language, wonderful as it is in many ways, is
terrible about this.
One thing isn't the language's fault. Macro languages, if they are
similar to the underlying language for which they emit code, are often
hard to read, because the data items (the strings which are building
blocks for the emitted code) look very much like the macro code. (You
can't win this one. If the macro syntax and the underlying language's
syntax are quite different, macros are easier to read, IF you are
thoroughly familiar with both syntaxes, and have them both clear in
your mind simultaneously.)
But SAS made it harder yet. The SAS macro language is one of what were
once called "interpreted" languages. That isn't the essence of such
languages; the essence is, programs in the language can generate or
modify text which then becomes part of the same program. That's now
deeply imbedded in the SAS macro language; for example, it would be
hard to do without &&name&sfx to simulate arrays of macro variables.
As a result, though, macro programs are riddled with 'quoting'
problems: with, that is, problems distinguishing what's program text,
and what's data being processed. (It doesn't help that emitted text can
be program code, or comments, or character literals at the SAS level.)
The problem is so severe that being expert at 'quoting' -- that is, at
telling code from data -- is the main mark of a macro maven. And even
the best get tangled up: look at the recent thread on the meaning of
%nrbquote. Medieval theology, move over!
This tangle is a pity, because, as I've said, there are some wonderful
things about the macro language. One is how it's integrated with SAS
as, in part, a 'scripting' language, i.e. one in which macros can have
cognizance of SAS run-time quantities. (Go over to the SPSSX-L list, if
you like, and look at the hoops that have to be jumped through to use
the value of a variable, or the current date, in the name of an output
file. Or to do arithmetic, but that's a 'shallow' rather than a 'deep'
deficiency in SPSS macros.) Another is extremely simple: the single
global name space for macro parameters, so they can be set up anywhere
and used throughout a SAS program.
Yes, the SAS macro facility is very useful, and very powerful. But
'robust', in the sense I've used, it just ain't.