Date:         Fri, 7 May 2004 14:15:06 -0700
Reply-To:     cassell.david@EPAMAIL.EPA.GOV
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         "David L. Cassell" <cassell.david@EPAMAIL.EPA.GOV>
Subject:      Re: macro
Content-type: text/plain; charset=US-ASCII

Richard Ristow <wrristow@MINDSPRING.COM> brought up some interesting
points:
> That last is fair enough -- I've written JCL for money! (It sure
wasn't
> for love...)

Well, you have my sympathies.  :-)

> 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.

As I said, defining 'robust' is an exercise left to the reader.  :-)

If a key criterion is not hindering the writing of clear programs, then
I think that a *lot* of standard programming languages fail.  Plenty of
people
think that Perl by itself hinders the writing of clear programs.  (I
don't
agree, but that's me.)  I would list a few major languages like Lisp,
APL,
and Forth as languages which have features which many people feel
actively
hinder the utility of the language.  Then there are languages like
Eiffel
or Befunge which have additional 'features' which hinder working in the
language.  So I'm still listing SAS macro as a programming language.
But
I'm not denying your point.

> 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.)

Agreed.  Macro languages either look like your upper-level language and
have heinous features so that your parsers and lexers can distinguish
them,
or else are so different from the upper-level language that few can
learn
both languages and integrate them well.

> 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.

I'll add that the 'interpreted' nature isn't really the problem here.
It is the substitution mechanism needed for the parser to grok what we
throw at it.

> 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!

Every language has its own 'deep' theological issues.  Just look at the
ANSI C UseNet group to see C-ists argue vehemently over such topics.
And
there are dozens (if not hundreds) of deep intricacies in Perl.  But
Perl-ites
*like* it that way.

I think that Ian's presentation on macro quoting at SUGI 28 explained
much
of the mystery for the audience, and it was done in PowerPoint in less
than
an hour.

> 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.

I totally agree on the 'global namespace' issue.  Fortunately, we are
not
actually restricted to only-global or only-local with SAS macro
variables.

> Yes, the SAS macro facility is very useful, and very powerful. But
> 'robust', in the sense I've used, it just ain't.

Don't you want 'tangled' and 'intricate'?  Where's your sense of job
security?
:-)

David
--
David Cassell, CSC
Cassell.David@epa.gov
Senior computing specialist
mathematical statistician