David.Beasley@cm.cf.ac.uk (David Beasley) writes:
> Date: 26 Jan 93 16:03:19 GMT
> Organization: University of Wales College of Cardiff
>
> In article <116670051@otter.hpl.hp.com> sfk@otter.hpl.hp.com (Steve Knight) writes:
[sfk]
> >If I write
> > constant foo = {'dog'};
> >then the variable foo is immutable -- it always points to the same
> >location.
[db]
> Unless, of course there is a subsequent line such as:
> constant foo = ['something else'];
>
> Since you can easily redefine constants in this way, even these are mutable.
That's correct, but I suspect that what Steve meant is illustrated
by the following example.
constant x = 99;
define test();
x =>
enddefine;
test();
** 99
constant x = 77;
x =>
** 77
test();
** 99
define newtest();
x =>
enddefine;
newtest();
** 77
I.e. any code compiled between the two constant declarations of x
that uses x, does not access its value via the variable x (i.e. a
location in memory associated with the identifier "x"). Instead the
use of x compiles to code that points directly to whatever was
assigned to x. So it is as if the value of the constant were
actually used throughout instead of the variable name "x". When you
redeclare the constant and give it a new value, subsequent code
will use the new value.
Allowing this redeclaration and reassignment to a "constant" is of
course questionable, and can lead to errors if identifier names are
not chosen carefully to avoid clashes. But in an interactive
development environment designed to support rapid prototyping and
testing, it is necessary to allow a file including constant
declarations to be recompiled and for the constant value to be
changed. The simplest way to do this is to allow a new constant
declaration to permit one new assignment to the variable.
(This was previously not permitted and required the identifier to be
cancelled in between recompiling the file. This was often extremely
inconvenient. Instead the new constant declaration effectively
cancels the old constant identifier and starts a new one.)
Regarding Luc's point about the use of the word "variable" to
refer to constants: it is in a sense a variable, whose value is
changeable, as shown above, but between changes all compiled uses
are constant, and moreover, between re-declarations attempts to
compile code that assigns to the variable will produce an error;
define test3();
66 -> x;
;;; MISHAP - COMPILING ASSIGNMENT TO CONSTANT
;;; INVOLVING: x
Maybe instead of the word "constant" the declaration should have
taken the form
compile_as_constant x = 99;
In fact, I tend to refer to x as an identifier rather than as a
variable, if it's a constant! In Pop-11 it is strictly the
identifier that has the syntactic property of compiling as a
constant and preventing reassignments. For constants we have the
following entities:
<word> -->-- <identifier> -->-- <value>
for non-constants we have
<word> -->-- <identifier> -->-- <variable> -->-- <value>
For compiled code involve constants we have
<code> -->-- <value>
For compiled code involving variables we have
<code> -->-- <variable> -->-- <value>
where <variable> is a location in memory associated with the
<identifier>, to which code involving the identifier refers. For
constants there is no such location accessible by compiled code.
It's only accessible during compilation.
Incidentally, "lconstant" (for lexically scoped constant
identifiers) is the same except that you cannot have two lconstant
declarations for the same identifier in the same lexical scope;
define test4();
lconstant x = 77;
x =>
lconstant x = 88;
;;; MISHAP - ILLEGAL ASSIGNMENT TO LCONSTANT
;;; INVOLVING: x
Aaron
--
--
Aaron Sloman,
School of Computer Science, The University of Birmingham, B15 2TT, England
EMAIL A.Sloman@cs.bham.ac.uk OR A.Sloman@bham.ac.uk
Phone: +44-(0)21-414-3711 Fax: +44-(0)21-414-4281
|