Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!wuarchive!cs.utexas.edu!hellgate.utah.edu!cdr.utah.edu!moore
From: moore%cdr.utah.edu@cs.utah.edu (Tim Moore)
Newsgroups: comp.lang.lisp
Subject: Re: Clarification of array semantics needed
Message-ID: <1990Nov29.120430.26713@hellgate.utah.edu>
Date: 29 Nov 90 19:04:30 GMT
References: <11765@spool.cs.wisc.edu> <1990Nov20.101626.13488@hellgate.utah.edu> <11839@spool.cs.wisc.edu>
Organization: University of Utah CS Dept
Lines: 64

In article <11839@spool.cs.wisc.edu> bothner@sevenlayer.cs.wisc.edu (Per Bothner) writes:
>In article <1990Nov20.101626.13488@hellgate.utah.edu> moore%cdr.utah.edu@cs.utah.edu (Tim Moore) writes:

>>>* Page 456, line 12: "but this may be achieved ... by creating
>>>a new array and modifying the array argument to be displaced..."
>>>seems to be contradicted by p 457, line 19.
>>>
>>p457, line 19 applies only to arrays that weren't created with the
>>:adjustable argument to make-array, and thus isn't really relevent.
>
>But p 457 lines 19- still contradict p 456 lines 12-15. The new semantics
>says that one is *never* allowed to "modify the ARRAY argument to be
>DISPLACED to the new array." It looks like this paragraph (on p 456)
>should have been removed for the 2nd edition, but wasn't.
>

I don't think it says that at all. It does say that if adjust-array is used
on an array that was not created with :adjustable (or for which
adjustable-array-p is not true) then it is unspecifed whether or not
the array returned by adjust-array is eq to the original array.
However, p457 also says "If the array returned by adjust-array is not
eq to its first argument, the original array is unchanged and does not
share storage with the new array." This might cause some confusion; I
think it clearly only applies to non-adjustable arrays. For adjustable
arrays, the result is always eq to the array argument.

It might be a good idea to keep some of the possible implementation
techniques in mind:

* A simple array is a pointer to the contents of the array.
Adjustable (and possibly displaced) arrays need a header for
indirection, and thus are fundamentally different from simple arrays.
adjust-array can't alter simple arrays, and needs to return a new array.

* Any array object is a pointer to an array header, which points to
the array contents. Some implementations (like KCL) use this technique
to simplify allocation and garbage collection. In this case all arrays
are adjustable "in place", and adjust-array can always return its (modified)
argument.

* The hardware supports invisible forwarding pointers. Pretty much the
same as the second case.

>>>If I have:
>>>	(setq B (adjust-array A ...))
>>>does the phrase "the result" refer to B or A?
>>>
>>Both. The whole point of adjust-array is that its return value is eq
>>to its array argument, as long as A is adjustable.
>
>The question is for when A is *not* adjustable.
>My reading is that then the adjust-array is equivalent to
>a make-array, except that A is used as a kind of default :initial-contents.
>Is this a reasonable reading?

Yes, it is reasonable for an implementation to behave that way, but it
is not the only possible behavior.
>--
>	--Per Bothner
>bothner@cs.wisc.edu Computer Sciences Dept, U. of Wisconsin-Madison

Tim Moore                    moore@cs.utah.edu {bellcore,hplabs}!utah-cs!moore
"Ah, youth. Ah, statute of limitations."
		-John Waters