home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.pop
- Path: sparky!uunet!inmos!fulcrum!bham!bhamcs!axs
- From: axs@cs.bham.ac.uk (Aaron Sloman)
- Subject: Re: Re: dlocals etc. (and shallow binding)
- Message-ID: <C1ID7x.FDE@cs.bham.ac.uk>
- Summary: constants are immutable in previously compiled code
- Sender: news@cs.bham.ac.uk
- Nntp-Posting-Host: emotsun
- Organization: School of Computer Science, University of Birmingham, UK
- References: <C1CAwq.8up@cs.bham.ac.uk> <116670051@otter.hpl.hp.com> <1993Jan26.160320.27465@cm.cf.ac.uk>
- Date: Wed, 27 Jan 1993 10:31:09 GMT
- Lines: 126
-
- 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
-