home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / pop / 217 < prev    next >
Encoding:
Internet Message Format  |  1993-01-25  |  1.5 KB
  1. From: sfk@otter.hpl.hp.com (Steve Knight)
  2. Date: Mon, 25 Jan 1993 12:02:32 GMT
  3. Subject: Re: Re: dlocals etc. (and shallow binding)
  4. Message-ID: <116670051@otter.hpl.hp.com>
  5. Organization: Hewlett-Packard Laboratories, Bristol, UK.
  6. Path: sparky!uunet!usc!sdd.hp.com!hpscit.sc.hp.com!hplextra!otter.hpl.hp.com!otter!sfk
  7. Newsgroups: comp.lang.pop
  8. References: <C1CAwq.8up@cs.bham.ac.uk>
  9. Lines: 26
  10.  
  11. Luc asks:
  12. > Pardon my ignorance, Steve, but what do you mean by mutable?
  13.  
  14. Allowed to change -- the inverse of constant.  Most variables in Pop
  15. are updated more than once in their dynamic lifetime and are therefore
  16. intrisincally mutable.  Some variables are allowed to change but provably
  17. are never assigned to more than once -- they are potentially mutable but
  18. can be treated as immutable (i.e. constant).
  19.  
  20. There is an ambiguity over whether (im)mutability just applies to the top-
  21. level of a datastructure or all levels.  e.g. If I write
  22.     constant foo = {'dog'};
  23. then the variable foo is immutable -- it always points to the same
  24. location.  However, its value is mutable. i.e.
  25.     'cat' -> foo(1);
  26. is legal and changes the value of foo.  So the question is whether it is
  27. really proper to talk of foo being immutable when it value can change?  In
  28. Pop, it turns out that the best way to use the term immutable is to only
  29. be concerned with the top-level.  This is because there are so few data
  30. structures in Pop which are non-assignable, the other usage would never
  31. apply.
  32.  
  33. Hope this helps!
  34.  
  35. Steve
  36.  
  37.