Re: Issue: DYNAMIC-EXTENT (Version 2)

["Steve Bacher (Batchman)" <SEB1525@draper.com>]

> From: "David A. Moon" <Moon@scrc-stony-brook.ARPA>
> Subject: Issue: DYNAMIC-EXTENT (Version 2)

> The following is where I disagree strongly with the proposal:
>
>      It is very important to note that it is the actual constructor operation
>      and not the resulting data type which determines the level of the object
>      referred to in the dynamic extent declaration. For example, in
>
>            (LET ((X (LIST 'A1 'B1 'C1))
>                  (Y (CONS 'A2 (CONS 'B2 (CONS 'C2 NIL)))))
>              (DECLARE (DYNAMIC-EXTENT X Y))
>              ...)
>
>      The list (A1 B1 C1) which is the initial value of X will have three cons
>      cells, all of which have dynamic extent. The cons (A2 . (B2 C2)) which is
>      the initial value of Y will have dynamic extent, but its cdr (B2 C2) will
>      have indefinite extent.
>
> I think this is the wrong way to look at it in general, and furthermore
> this means that backquote can't be used correctly with the
> DYNAMIC-EXTENT declaration, since there is no promise what backquote
> expands into. 
>
> ...
>
>            (LET ((X (LIST 'A1 'B1 'C1))
>                  (Y (CONS 'A2 (CONS 'B2 (CONS 'C2 NIL)))))
>              (DECLARE (DYNAMIC-EXTENT X Y))
>              ...)
>
> The "proper parts" of X are three conses, and the "proper parts" of Y
> are three other conses.  None of the symbols A1, B1, C1, A2, B2, C2, or
> NIL is a "proper part" of X or Y.  However, if a freshly allocated
> uninterned symbol had been used, it would have been a "proper part."
>
>    Date: 7 Dec 88 18:05 PST
>    From: masinter.pa@Xerox.COM
>
>    Version 2 of this writeup didn't mention one of the criticisms I sent on 1
>    July, namely:
>
>    "a) it is disturbing to introduce a construct within which a casual change
>    of (CONS X (LIST Y Z)) to  (LIST X Y Z) could introduce a serious bug
>    (e.g., if the tail were stashed away
>    somewhere.)"
>
> I quite agree with this.  My proposed alternative definition doesn't have any
> problems like this, since it is defined in terms of the actual object, not in
> terms of how it was constructed.
>

I agree strongly with the comments of Moon and Masinter.  For example, in our
implementation, the compiler source-transforms calls to LIST into nested
calls to CONS.  Under these circumstances, it is impossible to distinguish
between the cases in the various examples above for the purpose of determining 
which conses are subject to the DYNAMIC-EXTENT constraint.