[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FILTERs: Source-to-source code transformers
- To: RMS at MIT-MC
- Subject: Re: FILTERs: Source-to-source code transformers
- From: Jon L White <JONL at MIT-MC>
- Date: Fri ,30 Jan 81 18:31:00 EDT
- Cc: LISP-FORUM 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."