LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (May 2004, week 1)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
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
In-Reply-To:  <OF3D8FF360.F860D0A5-ON88256E86.00025047@epamail.epa.gov>
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 >09:31:58 -0600): > >>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 for love...)

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.


Back to: Top of message | Previous page | Main SAS-L page