[HARLEQUIN][Common Lisp HyperSpec (TM)] [Previous][Up][Next]


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:


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996, The Harlequin Group Limited. All Rights Reserved.