From: Per Bothner
Subject: Clarification of array semantics needed
Date: 
Message-ID: <11765@spool.cs.wisc.edu>
I'm trying to implement (in C++) CL arrays, but I
find CLtL:2 rather confusing on some of the details.
Perhaps someone here can help a poor non-Lisp-hacker (and
perhaps ANSI could be more specific about the details).

* If an array A is displaced to a vector B with a
fill-pointer, is B's fill-pointer ignored when
accessing A? That seems a reasonable interpretation
(confirmed by a simple test with kcl). It does make
the remark "(Note, however, that one can create a multidimensional
array that a *displaced* to a vector that has a fill pointer.)"
[p. 454, 6th line from bottom] seem rather irrelevant.
Or are *all* fill-pointers checked when following a chain
of displacements?

* Is the following legal?
	(setq A (make-array ... :adjustable t :displaced-to B))
A later (adjust-array A ...) should just change A's diminsions?
What if :initial-contents is given to the adjust-array?

* I find section 17.6 on adjust-array totally confusing.
The various "clarifications" don't help. For example:

* 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.

* The whole "clarification" on p 458 is unclear to me.
If I have:
	(setq B (adjust-array A ...))
does the phrase "the result" refer to B or A?


--
	--Per Bothner
·······@cs.wisc.edu Computer Sciences Dept, U. of Wisconsin-Madison
From: Tim Moore
Subject: Re: Clarification of array semantics needed
Date: 
Message-ID: <1990Nov20.101626.13488@hellgate.utah.edu>
In article <·····@spool.cs.wisc.edu> ·······@sevenlayer.cs.wisc.edu (Per Bothner) writes:
>I'm trying to implement (in C++) CL arrays, but I
>find CLtL:2 rather confusing on some of the details.
>Perhaps someone here can help a poor non-Lisp-hacker (and
>perhaps ANSI could be more specific about the details).
>
>* If an array A is displaced to a vector B with a
>fill-pointer, is B's fill-pointer ignored when
>accessing A? That seems a reasonable interpretation
>(confirmed by a simple test with kcl). It does make
>the remark "(Note, however, that one can create a multidimensional
>array that a *displaced* to a vector that has a fill pointer.)"
>[p. 454, 6th line from bottom] seem rather irrelevant.
>Or are *all* fill-pointers checked when following a chain
>of displacements?

It's my interpretation that fill pointers are not checked when
following a chain of displacements. The final target of the
displacement chain is supplying storage, but not any information about
its dimensions (except maybe for a sanity check at the creation of the
displaced array). Note that the fill pointer isn't an absolute limit
on the size of the accessable part of a vector; you can always use
aref to access any element of a vector, fill pointer or no.

>
>* Is the following legal?
>	(setq A (make-array ... :adjustable t :displaced-to B))
>A later (adjust-array A ...) should just change A's diminsions?
>What if :initial-contents is given to the adjust-array?
>
(adjust-array A ...) can do several different things, depending on its
arguments. If A was originally displaced to B and :initial-contents is
specified to adjust-array, then A won't be displaced to B anymore.
Note that you can't specify both :initial-contents and :displaced-to.

>* I find section 17.6 on adjust-array totally confusing.
>The various "clarifications" don't help. For example:
>
>* 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.

>* The whole "clarification" on p 458 is unclear to me.
>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.

>
>--
>	--Per Bothner
>·······@cs.wisc.edu Computer Sciences Dept, U. of Wisconsin-Madison

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