[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
**DRAFT** issue CONSTANT-COLLAPSING
- To: firstname.lastname@example.org
- Subject: **DRAFT** issue CONSTANT-COLLAPSING
- From: barmar@Think.COM
- Date: Mon, 9 Jan 89 02:26:26 EST
- In-reply-to: Sandra J Loosemore's message of Sat, 7 Jan 89 11:48:52 MST <8901071848.AA08925@defun.utah.edu>
Here's my suggestion on how to define when constants may be collapsed.
It is based on a variant of the old railroad-track definition of EQ.
The general idea is that two objects may be collapsed into one object
unless there would have been a way to detect the difference between
the two original objects. In the case of ordinary objects consed at
runtime, this means that if there's a way to modify the contents of an
instance of a type then instances of that type may not be collapsed
(because modifying instance-1 would cause instance-2 to change).
If CONSTANT-MODIFICATION:DISALLOW is approved, then the above rule can
be used to derive a "coalescing predicate". Any two constants may be
collapsed if the results of all accessing operations on the objects
would produce collapsable results. These operations should include any
operations for accessing the contents of the object (CAR, CDR, AREF,
DEFSTRUCT-defined accessors, etc.), and functions for returning
attributes of the object (LENGTH, TYPE-OF, FILL-POINTER, etc.). I
believe that any EQUAL objects are collapsable under this definition,
so this more complex predicate need only be used when deciding whether
to collapse non-EQUAL objects.