Issue DESTRUCTIVE-OPERATIONS Writeup

Forum:		Public Review

Issue:		DESTRUCTIVE-OPERATIONS

References:	Dalton's public review comment #5 (X3J13/92-2005)

		Section 3.1.2.1.3 (Self-Evaluating Objects), p 3-9

		QUOTE, p 3-65

Category:	CLARIFICATION

Edit history:	30 Dec 1992, Version 1 by Loosemore

Status:		Proposal SPECIFY passed (7+4)-1 on letter ballot 93-306



Problem description:


  Section 3.1.2.1.3 (Self-evaluating objects) states that the

  "consequences are undefined if literal objects, including

  self-evaluating objects, are destructively modified.  A

  similar rule appears on p. 3-65 in the description of QUOTE.


  What counts as part of such an object for the purposes of this

  rule and consequently cannot be modified?


  It is important to resolve this, because users do such things

  as put hash table literals in code and then add new key-value

  associations.  It is not clear whether or not this is permitted.

  It is not even clear whether a symbol's property list counts as

  part of the symbol for the purposes of this rule.


  Other places in the standard that refer to limitations on destructive 

  operations (such as sections 3.6 and 3.7, or the discussion of

  compiler-macros), are similarly vague about exactly which operations

  are considered "destructive".



Proposal (DESTRUCTIVE-OPERATIONS:SPECIFY):


  Specify that the following operations are considered destructive:


  random-state

    Using it as an argument to the function RANDOM.


  cons

    Altering or destructively modifying the CAR or CDR of the cons.


  array

    Altering or destructively modifying any array element;

    changing the fill pointer, dimensions, or displacement of

    the array (regardless of whether the array is actually adjustable);

    or altering the contents of any array that is displaced to this array

    or that otherwise shares its contents with this array.


  hash-table

    Altering or destructively modifying any key or its corresponding

    value, or adding or removing entries from the hash table.


  structure-object

    Altering or destructively modifying the contents of any slot.


  standard-object

    Altering or destructively modifying the contents of any slot, or

    changing the class of the object.


  readtable

    Altering the readtable-case; altering the syntax type of any

    character in this readtable; altering the reader macro function

    associated with any character in this readtable; or altering the

    reader macro functions associated with characters defined as 

    dispatching macro characters in this readtable.


  stream

    Performing I/O operations on the stream, or closing the stream.


  all other types

  (including number, character, symbol, package, pathname, function,

  method, method-combination, condition, restart)

    There are no destructive operations defined on these data types.

    


Rationale:


  It solves the problem in a way that is generally consistent with 

  what is considered to be a component of an object for the purposes

  of determining similarity of constants.



Current practice:


  Unknown.



Cost to implementors:


  Unknown.



Cost to users:


  Unknown.



Aesthetics:


  Specifying this behavior is more aesthetic than leaving it vague.



Editorial impact:


  Probably the easiest way to handle this is to add a new subsection

  to section 3.7 containing the list above, and add appropriate references

  (e.g., in the glossary entry for "destructive").



Discussion: