many DISPLACEs

[JONL at MIT-MC (Jon L White)]

I'm perfectly happy with either the current definition of DISPLACE,
or with the one proposed by RMS, and am all in favor of "giving the
user what he wants".  But before we go out to take a hasty vote,
it might be a good idea to examine all the consequences of the
more "totalitarian" choice.  For example,
1) Should the functions be called "DISPLACE", since its action is
   more of a macro-expansion shunting.  Would the naive user be
   aware that could not use "DISPLACE" for displacement, due to the
   extra cruft pushed in.
2) Some macro-expansions take a monsterous amount of code, and produce
   even more - the "DISPLACED" scheme saves both around, with no
   choice available to the user, so that gc may be impacted.  Admittedly
   many users would like to be able to retrieve the source that the
   expansion came from, but then again most wouldn't go to any effort
   to save it.  see 3.
3) The current definition is essentially the one that has been in the
   LISP lore for the past 12 years, and one advantage of putting it
   in the "system" is that it can become the SUBR that it rightly is
   rather than hacking it in as another level of MACRO.  Its persistent
   use, in this form, would not seem to support the statement "Putting
   in any other sort of DISPLACE [than SDISPLACE] is tantamount to not
   putting in any, but creating some random system function instead."
4) My suggestion of a standard MACRO libaray, which would supply
   SDISPLACE (or better yet, MACRO-DISPLACE), doesn't seem to require
   that "each user must define it himself".  Or at least I didn't 
   think so.  Anyway, there are probably hordes of users who wont displace
   anything, but will be content with ordinary macro expansion.  How
   dull!  But if I read the most recent rmsuggestion correctly, we would
   have to require everyone to use the new "SDISPLACE" form of macros
   in order for automatic code analysis programs to have any success.
   Hence the appellation "totalitarian".