[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
new, improved defining macros proposal
- To: email@example.com
- Subject: new, improved defining macros proposal
- From: firstname.lastname@example.org (Gail Zacharias)
- Date: 24 May 88 18:17:07 EDT (Tue)
- Cc: email@example.com
- In-reply-to: Sandra J Loosemore's message of Tue, 24 May 88 13:37:06 MDT <8805241937.AA04849@cs.utah.edu>
I just started receiving this mailing list, so my apologies if this has been
DEFCONSTANT: ... (If the initial
value is a constant, however, an implementation is allowed to
substitute the constant value for references to the named constant
during subsequent compilation.)
I have a problem with this. The compiler shouldn't have licence to substitute
for the variable without fully implementing the semantics of DEFCONSTANT.
In particular, under this proposal, would the DEFCONSTANT's with constant
initial values be "evaluable at compile time" in the sense used in the
description of DEFMACRO? I.e. would the following work?
(DEFCONSTANT FOO 'FOO)
(DEFMACRO FOO () `',FOO)
(DEFVAR *FOO* (FOO))
In addition, the distinction between constant/non-constant initial value is
artificial and potentially ambiguous in the face of differing constant-folding
(DEFCONSTANT FOO 17)
(DEFCONSTANT BAR (ASH 1 FOO))
Are compilers allowed to substitute for BAR?
I think toplevel DEFCONSTANT should either be treated like DEFMACRO (i.e.
implicitly compile-time: initial value "must be evaluable at compile time" and
the binding must be made available to other compile-time code) or like
DEFVAR/DEFPARAMETER (implicitly load-time: compiler recognizes the variable as
special, but it is not allowed to substitute the value). I don't have a
strong preference either way (since you can always get "the other" semantics
via eval-when), but I don't like the proposed mixture of the two.