Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!snorkelwacker.mit.edu!bloom-beacon!dont-send-mail-to-path-lines
From: lyn@altdorf.ai.mit.EDU (Franklyn Turbak)
Newsgroups: comp.lang.scheme
Subject: Why macros impair readability
Message-ID: <9103071300.aa28959@mc.lcs.mit.edu>
Date: 7 Mar 91 17:59:13 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 102


This a response to Mark Friedman's evaluation of my analysis of macro
readability:

     > I think that his arguments are sound but his premise is faulty.
     >
     > In particular, after presenting many reasonable interpretations of the
     > term "readable" he chooses the least useful. He uses the term to mean 
     > "easy to reason about locally". The problem is that for large (and
     > well abstracted) programs local reasoning gets you very little
     > information. 

I agree wholeheartedly; my definition of "readability" *is* weak and not
very useful.  However, it's the only one I could think of at the time
of writing that allowed me to raise the set of points I wanted to raise:
that macros complicate reasoning about order of evaluation, static scope, 
first-classness, and debugging. 

I'd rather have a much stronger notion of readability that more people
find in tune with their intuitions.  From the discussions so far,
there's a lot of people who *do* feel that macros can make programs
hard to read.  My goal is to understand better *why* they feel this
way.  

Over the years, I personally have come to view the macro
as a kind of powerful drug; its judicious use can improve programs,
but its abuse leads to programs that are hard to read.  But why do I 
feel this way?  I assume it's because I've gotten "burnt" too many 
times when trying to read code that contains lots of macros.  I wish 
I had written down or could remember all these situations --- then I'd
have at chance at analyzing exactly what the difficulties were and
how my feelings about macros developed.  Maybe the macros tended to
introduce gratuitous syntax,  Maybe they were often written or documented
poorly.  Maybe I just didn`t have a good enough model of macros to 
understand what they meant or why they were being used.  Unfortunately,
I don`t remember these situations, and am left with the task of
rationalizing my feelings.  

My analysis was only a first attempt at this task. It is not
convincing in many ways and needs to be improved.  I'm hoping that
further discussion on this mailing list will elucidate the 
fundamental issues involved in the effects of macros on readability.

     > For example, consider the following procedure:

     > (define (foo bar)
     >   (mumble ((grumble bar)
     > 	          baz
     >            fumble)
     >           zaz)
     >   grok
     >   (((bar))))

     > Would it really help to know that grumble is a macro?  Unless you know
     > what grumble really does (or at least what it is supposed to do) the
     > issue of whether it is a macro or a procedure is fairly moot.  And in
     > the process of discovering what grumble actually does you will find
     > out whether it is macro or a procedure.

     > Now admittedly, macros are, on the whole, harder to figure out than
     > procedures, but that is not a issue of local readability. A
     > sufficiently complex macro (or procedure) must be well documented.
     > Higher level macro decription languages like extend-sytax help a lot
     > here also.

Yes, the local reasoning criterion is weak.  The key to a more usable
definition involves formalizing your intuition that macros "are harder
to figure out than procedures".  What makes them harder to figure out, 
and how does this impact on readability?

I am working on an improved model of "readability" to better handle
your objection.  The basic idea is that macros are harder than
procedures for the reader to model behaviorally because of the various
funky things that can be done in complex desugarings.  So
understanding (and remembering for later use) macro definitions and
calls requires more cognitive overheard than procedure definitions and
calls of similar syntactic complexity.  Maybe more limited versions
of syntactic abstraction (like EXTEND-SYNTAX) are sufficiently 
constrained to be more amenable to behavioral modelling than general
macro facilities.

Obviously, there are a lot of details to be worked out here.  Does 
anyone else who believes that macros impair readability have any 
ideas along these lines?

     > Your specific arguments against macros are well taken, but they seem
     > to imply a certain naive view (not that I think that Franklyn is naive
     > in any way :-) of the Scheme evaluation model. Scheme
     > is not the lambda calculus and it's not referentially transparent.
     > Macros do add extra comlexity, but I don't feel that they
     > qualitatively change the rules of the game. More importantly, they
     > give us another powerful abstraction mechanism. 

You say that macros are just another abstraction mechanism that do not
qualitatively change the rules of the game.  But then why is it that
syntactic abstraction and procedural abstraction evoke such different
responses with regard to readability.  I rarely (if ever) hear
programmers complaining that code was hard to read because it
contained procedures, but *do* hear programmers making these kinds
of claims about macros.

- Lyn -