Re: FILTERs: Source-to-source code transformers

[Jon L White <JONL at MIT-MC>]

Re your note about "can't understand ... [things] .. wrong with optimizers 
on the Lispm." 

Although I mentioned displace-ings in MacLISP, there are far more
   general side-effects than that (like updating a data-base);  true, 
   one could always frivously copy the cons-cell in order to signal that 
   something was done, but isn't this the out-dated way of returning
   two items of information? (see point 4 below).

I believe you may not fully appreciate why users, as opposed to the 
   compiler-maintainers, want such a feature.  Such a thing is "in demand" 
   with users because they want a chance to "filter" certain source-code 
   expressions without usurping any prior functional definitions;
   otherwise, a macro-definition would be just dandy.   Thus one could 
   transform (RETURN X Y) into (RETURN (VALUES X Y)) without getting into 
   the kind of loop that a macro-definition for RETURN would cause.

InterLISP, for over a decade, has had three varieties of macros,
   one of which corresponds roughtly to what I'm now calling "Filters".
   Its a loss that their Compiler Macros don't interpret;  just ask any 
   InteLISP user.   As QUUX pointed out, there may be genuine interest in 
   making these things interpretable -- the fact that YOU haven't used them 
   that way doesn't argue against it.  

Such a "Filter" can do everything that a LISPM "optimizer" can -- if
   it's the intention of the LISPM community not to have the more general
   mechanism, then that seems reason enough to let the more general,
   user-oriented facility have a different name.

Your postscript seems to imply that there is something wrong with multiple
   value;  Really?  Don't they work on the LISPM?
  "PS. The reason why just returning the transformed form is better
   for compatibility is that it doesn't require multiple values."