home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / pop / 224 < prev    next >
Encoding:
Text File  |  1993-01-27  |  4.5 KB  |  140 lines

  1. Newsgroups: comp.lang.pop
  2. Path: sparky!uunet!inmos!fulcrum!bham!bhamcs!axs
  3. From: axs@cs.bham.ac.uk (Aaron Sloman)
  4. Subject: Re: Re: dlocals etc. (and shallow binding)
  5. Message-ID: <C1ID7x.FDE@cs.bham.ac.uk>
  6. Summary: constants are immutable in previously compiled code
  7. Sender: news@cs.bham.ac.uk
  8. Nntp-Posting-Host: emotsun
  9. Organization: School of Computer Science, University of Birmingham, UK
  10. References: <C1CAwq.8up@cs.bham.ac.uk> <116670051@otter.hpl.hp.com> <1993Jan26.160320.27465@cm.cf.ac.uk>
  11. Date: Wed, 27 Jan 1993 10:31:09 GMT
  12. Lines: 126
  13.  
  14. David.Beasley@cm.cf.ac.uk (David Beasley) writes:
  15.  
  16. > Date: 26 Jan 93 16:03:19 GMT
  17. > Organization: University of Wales College of Cardiff
  18. >
  19. > In article <116670051@otter.hpl.hp.com> sfk@otter.hpl.hp.com (Steve Knight) writes:
  20. [sfk]
  21. > >If I write
  22. > >    constant foo = {'dog'};
  23. > >then the variable foo is immutable -- it always points to the same
  24. > >location.
  25.  
  26. [db]
  27. > Unless, of course there is a subsequent line such as:
  28. >     constant foo = ['something else'];
  29. >
  30. > Since you can easily redefine constants in this way, even these are mutable.
  31.  
  32. That's correct, but I suspect that what Steve meant is illustrated
  33. by the following example.
  34.  
  35.     constant x = 99;
  36.  
  37.     define test();
  38.         x =>
  39.     enddefine;
  40.  
  41.     test();
  42.     ** 99
  43.  
  44.     constant x = 77;
  45.  
  46.     x =>
  47.     ** 77
  48.  
  49.     test();
  50.     ** 99
  51.  
  52.     define newtest();
  53.         x =>
  54.     enddefine;
  55.  
  56.     newtest();
  57.     ** 77
  58.  
  59. I.e. any code compiled between the two constant declarations of x
  60. that uses x, does not access its value via the variable x (i.e. a
  61. location in memory associated with the identifier "x"). Instead the
  62. use of x compiles to code that points directly to whatever was
  63. assigned to x. So it is as if the value of the constant were
  64. actually used throughout instead of the variable name "x". When you
  65. redeclare the constant and give it a new value, subsequent code
  66. will use the new value.
  67.  
  68. Allowing this redeclaration and reassignment to a "constant" is of
  69. course questionable, and can lead to errors if identifier names are
  70. not chosen carefully to avoid clashes. But in an interactive
  71. development environment designed to support rapid prototyping and
  72. testing, it is necessary to allow a file including constant
  73. declarations to be recompiled and for the constant value to be
  74. changed. The simplest way to do this is to allow a new constant
  75. declaration to permit one new assignment to the variable.
  76.  
  77. (This was previously not permitted and required the identifier to be
  78. cancelled in between recompiling the file. This was often extremely
  79. inconvenient. Instead the new constant declaration effectively
  80. cancels the old constant identifier and starts a new one.)
  81.  
  82. Regarding Luc's point about the use of the word "variable" to
  83. refer to constants: it is in a sense a variable, whose value is
  84. changeable, as shown above, but between changes all compiled uses
  85. are constant, and moreover, between re-declarations attempts to
  86. compile code that assigns to the variable will produce an error;
  87.  
  88.     define test3();
  89.         66 -> x;
  90.     ;;; MISHAP - COMPILING ASSIGNMENT TO CONSTANT
  91.     ;;; INVOLVING:  x
  92.  
  93. Maybe instead of the word "constant" the declaration should have
  94. taken the form
  95.     compile_as_constant x = 99;
  96.  
  97. In fact, I tend to refer to x as an identifier rather than as a
  98. variable, if it's a constant! In Pop-11 it is strictly the
  99. identifier that has the syntactic property of compiling as a
  100. constant and preventing reassignments. For constants we have the
  101. following entities:
  102.  
  103.     <word> -->--  <identifier> -->-- <value>
  104.  
  105. for non-constants we have
  106.  
  107.     <word> -->--  <identifier> -->-- <variable> -->-- <value>
  108.  
  109. For compiled code involve constants we have
  110.  
  111.     <code> -->-- <value>
  112.  
  113. For compiled code involving variables we have
  114.  
  115.     <code> -->-- <variable> -->-- <value>
  116.  
  117. where <variable> is a location in memory associated with the
  118. <identifier>, to which code involving the identifier refers. For
  119. constants there is no such location accessible by compiled code.
  120. It's only accessible during compilation.
  121.  
  122. Incidentally, "lconstant" (for lexically scoped constant
  123. identifiers) is the same except that you cannot have two lconstant
  124. declarations for the same identifier in the same lexical scope;
  125.  
  126.     define test4();
  127.         lconstant x = 77;
  128.         x =>
  129.         lconstant x = 88;
  130.     ;;; MISHAP - ILLEGAL ASSIGNMENT TO LCONSTANT
  131.     ;;; INVOLVING:  x
  132.  
  133. Aaron
  134. --
  135. -- 
  136. Aaron Sloman,
  137. School of Computer Science, The University of Birmingham, B15 2TT, England
  138. EMAIL   A.Sloman@cs.bham.ac.uk  OR A.Sloman@bham.ac.uk
  139. Phone: +44-(0)21-414-3711       Fax:   +44-(0)21-414-4281
  140.