#

## 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:

Copyright 1996-2005, LispWorks Ltd. All rights reserved.