Retraction and Resubmission

[Perry Wagle <wagle%indiana.csnet@csnet-relay.arpa>]

  I noticed later that my suggestion about the renaming of "mapc" is
somewhat bogus, I apologize:

  Mapcar-type functions have two primary operating parameters: (1) the order
in which the list is processed, (2) a resultant value from whether the list
is copied, side-effected, or forgotten.

  The current "mapcar" processes in arbitrary order and returns the copied
list.  The current "mapc" processes in left-to-right order and forgets the
list (returning nothing).  Quite, ahem, different.

  (The most direct interpretation of a function named "mapcar!" would be one
that set-car!ed the list, returned the side-effected list, and was open as
to whether to process in arbitrary or left-to-right order.)


  I would have use for (in order of frequency):

(1)  arb-order, copy list, return list.  (the current mapcar).
(2)  LR-order, copy list, return list.  I don't like set-car!ing cons-cells,
     but I make much use of files and continuations, so order matters a lot.
(3)  LR-order, forget list, return nothing. (the current mapc).  Print lists.
(4)  LR-order, side-effect list, return list.  If keeping same cons-cell is
     important for some reason.

  Perhaps only a subset of the set of useful mapcar variations should be
provided by the system - the two that already are?  The points would still
remain of denoting their status as a member of this grouping by using the
word "map" in the name, of having special marking for functions that
guarantee left-to-right evaluation or processing, and having a naming
convention for the others should they ever be realized.

  My suggestion is to distinguish between the arbitrary and left-to-right
list processing but starting off with two roots "map" and "map/lr",
respectively.  Futhermore, since there are three values returned - a copied
list, a set-car!ed list, and nothing at all - "copy", "list!", and "" (null),
respectively.  Then the four hypothetical functions above would be named:

(1)	"map->copy"
(2)	"map/lr->copy"
(3)	"map/lr"
(4)	"map/lr->list!" or "map/lr->same!" or ... (?)

  (Note that while there would be no reasonable value for (a fifth) "map" to
return, while "map/lr" could return the value of the last mapping.)

						Perry Wagle