[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Versions 2a,2b,2c)

Ok, three proposals follow. There isn't enough overlap for me to to bother
trying to  share their components. Please just vote for one or more and
hopefully we can discard the unpopular ones as it becomes more clear which
they are. I would hope that ultimately we can present a single proposal
to X3J13, but I can't at this time figure out which that will be.
 -kmp

-----Version 2a (ADJUST-ARRAY-NOT-ADJUSTABLE:IMPLICT-COPY)-----
Issue:        ADJUST-ARRAY-NOT-ADJUSTABLE
References:   ADJUST-ARRAY (p297)
Category:     ADDITION
Edit history: 22-Apr-87, Version 1 by Pitman
	      15-Nov-88, Version 2a by Pitman
Status:	      For Internal Discussion

Problem Description:

  The description of ADJUST-ARRAY on pp297-298 says that it is ``not permitted
  to call ADJUST-ARRAY on an array that was not created with the :ADJUSTABLE
  option.''

Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE:IMPLICIT-COPY):

  Change the definition of ADJUST-ARRAY to say that any array is a valid argument.
  Say that if the array is not adjustable or if its old rank is not compatible
  with the newly specified rank, then a new array will be created and returned.

  In the case where the argument was not adjustable and a new array was returned,
  an implementation is permitted to (but not required to) recycle the storage
  backing up the original array. It is an error to continue to use an array
  which was not adjustable.

  As with other destructive operations (most of which have names starting with
  the letter "N"), are encouraged to use this for value wherever possible and
  would be told that they can rely on the array to be adjusted `for effect'
  only when it was adjustable and the new rank matched the old.

Rationale:

  ADJUST-ARRAY offers features which are offered by no other function and which
  are useful in cases involving non-adjustable arrays (for what amounts to copying).
  This change would allow an expression such as:

    (SETQ X (ADJUST-ARRAY X ...))

  to work reliably. Those desiring the old behavior could do:

    (IF (OR (NOT (ADJUSTABLE-ARRAY-P X))
	    (NOT (EQUAL (ARRAY-RANK X) (LENGTH NEW-DIMENSIONS))))
	(ERROR "Array cannot be adjusted."))
  
  to get the old style error checking.

Current Practice:

  Probably no one implements this extension.

Adoption Cost:

  Although this change is not trivial, it is localized and would probably not
  require an excessive amount of work to install. Probably most of the necessary
  routines already exist and it's just a matter of offering an interface.

Benefits:

  In cases where a user would want to adjust an array but the array is not
  adjustable, he may well decide to try to simulate the contract of 
  ADJUST-ARRAY in copying the array. This can be tedious and may be error
  prone. It would be better for such code to be written once, efficiently 
  and uniformly, and then offered to the user in a well-packaged way.

  Some implementations have implementation-specific array attributes.
  A COPY-ARRAY program written in Common Lisp cannot correctly copy
  arrays with implementation-dependent attributes, but the implicit array
  copying feature described here could preserve such attributes. As such,
  this feature could help Common Lisp code to be more compatible with
  native data objects.

Conversion Cost:

  No correct user code currently tries to modify arrays which are 
  non-adjustable, so this change is technically upward compatible.

  Some advanced code-walking tools which believe that this function 
  works only by side-effect would have to be modified very slightly
  to know that its return value was of interest.

Aesthetics:

  Some people think this change is unaesthetic because it loses
  potential error checking.

  Some people think the whole notion of :ADJUSTABLE is unaesthetic,
  and so this change improves aesthetics.

  Some people worry that a delete like the `DELETE bug' (failure to
  SETQ the array back) might lead to confusion. For that reason, they
  find this change unaesthetic.

Discussion:

  MACSYMA needed something like this.

-----Version 2b (ADJUST-ARRAY-NOT-ADJUSTABLE:SIGNAL-ERROR)-----
Issue:        ADJUST-ARRAY-NOT-ADJUSTABLE
References:   ADJUST-ARRAY (p297)
Category:     CLARIFICATION/CHANGE
Edit history: 22-Apr-87, Version 1 by Pitman
	      15-Nov-88, Version 2b by Pitman
Status:	      For Internal Discussion

Problem Description:

  The description of ADJUST-ARRAY on pp297-298 says that it is ``not permitted
  to call ADJUST-ARRAY on an array that was not created with the :ADJUSTABLE
  option.''

Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE:SIGNAL-ERROR):

  Change the definition of ADJUSTABLE-ARRAY-P to say that it will return T
  if and only if the array was created with :ADJUSTABLE T.

  Change the definition of ADJUST-ARRAY to say that it will signal an error
  if and only if the array to be adjusted was not created with :ADJUSTABLE T.

Rationale:

  Although implementations such as Genera which make adjustable arrays
  even when :ADJUSTABLE NIL is specified (or when not :ADJUSTABLE option
  is specified) are within the letter of the law, many argue that they
  are not within the spirit of the law. They argue that this `feature'
  just reduces error checking. The failure of ADJUST-ARRAY to recognize
  arrays which were not explicitly requested to be adjustable leads to
  portability problems when moving to other implementations which do not
  support this feature.

  Many users do not expect to have to do (SETQ X (ADJUST-ARRAY X ...)) when
  adjusting an array. If they expect ADJUST-ARRAY to work by side-effect,
  serious problems might be introduced by the IMPLICIT-COPY option above.

Current Practice:

  Symbolics Genera is incompatible with this proposal (though not with CLtL).

  Many implementations implement this proposal.

Adoption Cost:

  Some implementations may not have enough bits in their current
  array representation to represent the :ADJUSTABLE option. This may be
  true of Symbolics Genera -- I don't think anyone's done a full study of
  all array types on all processor types in order to prove
  whether this change is feasible or not.

Benefits:

  Portability of programs using ADJUST-ARRAY between some implementations
  is improved.

Conversion Cost:

  None to portable code. This change is technically upward compatible.

  Note however, that some implementation-specific code is affected
  adversely since :ADJUSTABLE T options would have to be added to some
  calls to MAKE-ARRAY in order to accomodate a more restrictive
  ADJUST-ARRAY.

Aesthetics:

  Some people think this change is very aesthetic because it increases
  the amount of error checking which can be done by ADJUST-ARRAY.

  Some people find the kind of error checking done by ADJUST-ARRAY to
  be gratuitous because they think the whole notion of :ADJUSTABLE is
  unaesthetic. To them, any attempt to enforce adjustability is an intrusion.

Discussion:

  None yet.


-----Version 2c (ADJUST-ARRAY-NOT-ADJUSTABLE:SIGNAL-ERROR+NEW-FUNCTION)-----
Issue:        ADJUST-ARRAY-NOT-ADJUSTABLE
References:   ADJUST-ARRAY (p297)
Category:     CLARIFICATION/CHANGE/ADDITION
Edit history: 22-Apr-87, Version 1 by Pitman
	      15-Nov-88, Version 2c by Pitman
Status:	      For Internal Discussion

Problem Description:

  The description of ADJUST-ARRAY on pp297-298 says that it is ``not permitted
  to call ADJUST-ARRAY on an array that was not created with the :ADJUSTABLE
  option.''

Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE:SIGNAL-ERROR+NEW-FUNCTION):

  Change the definition of ADJUSTABLE-ARRAY-P to say that it will return T
  if and only if the array was created with :ADJUSTABLE T.

  Change the definition of ADJUST-ARRAY to say that it will signal an error
  if and only if the array to be adjusted was not created with :ADJUSTABLE T.

  Introduce a function COPY-ARRAY which is like ADJUST-ARRAY which treats
  its arguments like COPY-ARRAY but which always produces a new array rather
  than modifying the original array.

Rationale: 

Current Practice:

  Symbolics Genera is incompatible with the part of this proposal which
  deals with ADJUST-ARRAY (though not with the analogous part of CLtL).
  Many other implementations are already compatible with that part of
  this proposal.

  Probably no one implements COPY-ARRAY.

Adoption Cost:

  Some implementations may not have enough bits in their current
  array representation to represent the :ADJUSTABLE option. This may be
  true of Symbolics Genera -- I don't think anyone's done a full study of
  all array types on all processor types in order to prove
  whether this change is feasible or not.

Benefits:

  Some implementations have implementation-specific array attributes.
  A COPY-ARRAY program written in Common Lisp cannot correctly copy
  arrays with implementation-dependent attributes, but a COPY-ARRAY
  function could. As such, the presence of COPY-ARRAY would help
  Common Lisp code to be more compatible with native data objects.

Conversion Cost:

  None to portable code. This change is technically upward compatible.

  Note however, that some implementation-specific code is affected
  adversely since :ADJUSTABLE T options would have to be added to some
  calls to MAKE-ARRAY in order to accomodate a more restrictive
  ADJUST-ARRAY.

Aesthetics:

  Some people think this change is very aesthetic because it increases
  the amount of error checking which can be done by ADJUST-ARRAY.

  Some people find the kind of error checking done by ADJUST-ARRAY to
  be gratuitous because they think the whole notion of :ADJUSTABLE is
  unaesthetic. To them, any attempt to enforce adjustability is an intrusion.

Discussion:

  MACSYMA needed something like this.