Re: issue QUOTE-SEMANTICS, version 2

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Fri, 17 Mar 89 13:48:43 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    > Date: Tue, 14 Mar 89 19:48 EST
    > From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    > 
    > I can't support either of the other two proposals because they use
    > the words "copying" and "coalescing" without defining their meaning.

    "Copying" means making an equivalent object that is similar as a
    constant, but not necessarily EQL, to the original. 

OK, but the proposal needs to be updated to say that, since I want
to base my vote only on what proposals actually say.

    I now have a question of my own about how proposal 
    COPYING-ALLOWED-BUT-NO-CONSTRAINTS interacts with issue
    CONSTANT-COMPILABLE-TYPES.  Maybe somebody who supports this 
    issue can help clarify this.

    On types where the notion of "similar as a constant" is left
    unspecified (for example, readtables), do you want this proposal to
    mean that copying is entirely forbidden, or that if the implementation
    has defined some behavior for "similar as a constant" on that type,
    that it can go ahead and copy?

I don't think I'm the one you were expecting a reply from, but if I
have to guess, I think it's the latter.  If an implementation is allowed
to extend "similar as a constant", then copying is consistent with the
definition of "similar as a constant" actually in force in that
implementation, not with the book definition.

    If copying is entirely forbidden in such a case, the implementation 
    cost for this proposal will be just as high as for proposal NO-COPYING.

Does this mean that as long as there is one data type for which copying
is forbidden, perhaps some user-defined data type, there is no implementation
advantage of COPYING-ALLOWED-BUT-NO-CONSTRAINTS over NO-COPYING?
If so, that would seem to knock COPYING-ALLOWED-BUT-NO-CONSTRAINTS
pretty completely out of the running.