>ANS wants ADJUST-ARRAY to copy the array implicitly when it is not
>adjustable. CLISP does not do that.
>Do you want to preserve the current behavior as an option?
No. I don't know what the current behaviour is. I suspect it is to signal an error. I see little reason to preserve error signaling behaviour.
Therefore I disagree with section (but who cares about my opinion)
"Cost to users:
This is a fully upward-compatible change from the user's standpoint."
They probably meant that portable programs cannot expect any array to be non-adjustable, therefore cannot expect an error from adjust-array.
However, I believe an implementation was well allowed to define which of its arrays (if any) would be non-adjustable and define that adjust-array would signal an error. Therefore, users could depend on this error-signaling behaviour in this implementation. That's what I would call a "cost to users".
-- Even though I vote "No" to behaviour preservation.
I don't like that it is left open whether a non-EQ array returned from adjust-array will be adjustable or not. That's an open issue and "unaesthetic".
(adjust-array does not have an :adjustable keyword... did they miss that?)
E.g. What can one say on
(adjustable-array-p (adjust-array X ...))
in the case where (adjustable-array-p X) is false?
I also find this
"Exceptional Situations: [to adjust-array]
An error of type error is signaled if fill-pointer is supplied and non-nil but array has no fill pointer."
not matching this cleanup issue.
Who cares about the original array's possible fill-pointer if it was non-adjustable anyway and adjust-array has to copy its contents? A :fill-pointer argument says something about the new array, not the old one.
My interpretation is that this was written in the old spirit of a non-copying adjust-array only working on adjustable arrays.
When (adjustable-array-p X) is false, why should
(adjust-array X :fill-pointer ...)
signal an error if X has no fill pointer, while
(let ((Y (adjust-array X)) ; copy it - adjust-array must not share storage
(make-array (array-dimensions Y) :displaced-to Y :fill-pointer ...))
would be fully portable?
"An error of type error is signaled if fill-pointer is supplied and non-nil but array *is actually adjustable and/but* has no fill pointer."
Maybe I should take this to cll??
IMHO, this cleanup issue comes as one on adjust-array, but it is rather one on deep-copying non-adjustable arrays (in implementations where such exist), whereas previously, content-sharing was allowed.
Finally, what's the effect of those "The following X3J13 cleanup issues, not part of the specification, apply to this section: ..."
If they are not part of ANSI CL, why bother with some?
BTW, how to get or when will I get "sufficient CVS Karma"?
Thursday, April 24, 2003, 5:22:53 PM, you wrote:
> BTW, how to get or when will I get "sufficient CVS Karma"?
Once I saw this message too. I don't remember exactly what I did to
get rid of it, but I believe I didn't reinstalled or configured
something. Maybe I had to relogin or maybe it was a sourceforge
I'm working on cross-platform execute, actually I tend to call the
low-level process launcher 'spawn' or 'fulfil' or 'launch'. I didn't
consider toplevel interface yet. The problem for me is actually in
stream.d - I had to and finally brought myself to review it all.