Re: issue DEFINING-MACROS-NON-TOP-LEVEL, version 6

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

> Date: Wed, 4 Jan 89 19:07:22 GMT
> From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
> 
> Even without the explicit provision for
> reordering, the compiler or interpreter could rewrite code in various
> ways provided that it was impossible (module efficiency) to tell that
> it had done so.  So what do we gain from the explicit provision?

This subissue seems to be confusing and nonintuitive to many people,
but after thinking about it for a while most people seem to agree that
it's reasonable.  I think it's better to say something explicitly in
the standard instead of just leaving people to be confused. 

> The key word seems to be "process".  The forms might be "processed"
> in an arbitrary order.  As far as I can tell, the only user-visible
> part of processing is macro-expansion.  Is that all there is to it,
> that the order in which macro calls are expanded is undefined?

The way I look at it, this part of the proposal does two things:

  (1) it says that users can rely on top-level forms in a file being
      processed in the order in which they appear.

  (2) it leaves the order of processing of non-top-level forms explicitly
      vague.

As things stand now, I think macro expansion is indeed the only thing
that users need to be concerned about in the second case.  For the first
case, there is also EVAL-WHEN and the handling of compile-time magic
associated with defining macros.

-Sandra
-------