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


I'm not sure whether I care one way or the other about this issue (of 
course, since DLA cares strongly, and I don't care, then that actually 
biases me _towards_ the proposal).

However, there is one persistent problem in dealing with Lisp users
that I'd like to see ameliorated somewhat.  This can be simply an
editorial point maybe, but I'd like to see a section in the spec
that concerns these "destructive" operations to say explicity that 
it is perfectly all right for them _not_ to destroy anything but 
instead to "cons" new results.  A typical part of your proposal is:

 (DELETE object sequence ...)
  when sequence is a list, is permitted to SETF any part, CAR or
   CDR, of the top-level list structure held in that sequence.
  when sequence is an array is permitted to change the dimensions
   of the array and to slide its elements into new positions without
   permuting them to produce the resulting array.

Unbelievable as it may sound, 3 out of 4 end user will read that
statemtent and understand it to mean that it _must_ "SETF the parts",
and will complain when it doesn't.   In particular, Lucid Common Lisp
will copy a vector rather than destructively update it unless it
is at least adjustable or fill-pointer'd (or both - can't remember 
whether adjustablility is required).  We can't adjust simple arrays,
and that means we can't adjust their length; so simply "sliding
things down" is not enough to effect the deletion.  [please, no
beats upon the dead horse of all arrays being ....]

In fact, the opening words of your proposal would bias the casual
reader into thinking that the "destructive" option is required; it
reads as
     Clarify that the way in which the destructive behavior of the
     operators below is achieved is explicitly vague in a number of ways,
How about adding the two-word subordinate clause as follows:
     Clarify that the way in which the destructive behavior, if any, of the
     operators below is achieved is explicitly vague in a number of ways,

A paragraph re-iterating the obvious may also be required.

-- JonL --