[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
**DRAFT** issue DEFCONSTANT-NOT-WIRED, version 6
- To: firstname.lastname@example.org
- Subject: **DRAFT** issue DEFCONSTANT-NOT-WIRED, version 6
- From: Barry Margolin <barmar@Think.COM>
- Date: Mon, 13 Mar 89 20:00 EST
- In-reply-to: <8903132328.AA02557@defun.utah.edu>
Date: Mon, 13 Mar 89 16:28:37 -0700
From: email@example.com (Sandra J Loosemore)
I have a terminology: use the term READ-ONLY in place of CONSTANT in the
suggested declaration, DEFINE-VARIABLE, etc. The term "constant" should
be reserved for things that are truly constant (pi, e,
number-of-bits-per-word, etc.); this is why they can be wired into code.
A symbol whose value might change due to external influences but which
should not be changeable by the user program is simply "read only".
It's like PROM -- the program can't change the value of a location, but
the user can plug in a new chip with a new value.
I like the idea of a DEF-READ-ONLY, which could expand into a DEFVAR
followed by a (PROCLAIM '(READ-ONLY <var>)). I also think that there
should be a NOT-READ-ONLY declaration; this way, if the constant needs
to be changed for some reason (e.g. reloading the file containing the
DEF-READ-ONLY form) there is a mechanism for turning off checking of
attempts to modify read-only variables. I'm not wedded to this idea,
though, because it means that read-only variables could not be put in
ROM (and depending on the system architecture, it could also prevent
them from being put in read-only memory segments).