bothner@sevenlayer.cs.wisc.edu (Per Bothner) (11/20/90)
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 bothner@cs.wisc.edu Computer Sciences Dept, U. of Wisconsin-Madison
moore%cdr.utah.edu@cs.utah.edu (Tim Moore) (11/21/90)
In article <11765@spool.cs.wisc.edu> bothner@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 >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
bothner@sevenlayer.cs.wisc.edu (Per Bothner) (11/30/90)
In article <1990Nov20.101626.13488@hellgate.utah.edu> moore%cdr.utah.edu@cs.utah.edu (Tim Moore) writes: ... a posting that clears up some of my questions. But there still seems to be inconsistencies in CLtL:2. >>* 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. >>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? -- --Per Bothner bothner@cs.wisc.edu Computer Sciences Dept, U. of Wisconsin-Madison
moore%cdr.utah.edu@cs.utah.edu (Tim Moore) (11/30/90)
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