[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue DEFINING-MACROS-NON-TOP-LEVEL, version 6
- To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
- Subject: Re: issue DEFINING-MACROS-NON-TOP-LEVEL, version 6
- From: email@example.com (Sandra J Loosemore)
- Date: Wed, 4 Jan 89 13:05:20 MST
- Cc: sandra <firstname.lastname@example.org>, email@example.com
- In-reply-to: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>, Wed, 4 Jan 89 19:07:22 GMT
> 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
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.