[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
issue DEFINE-OPTIMIZER, version 5
- To: email@example.com
- Subject: issue DEFINE-OPTIMIZER, version 5
- From: firstname.lastname@example.org
- Date: Tue, 21 Mar 89 12:10:40 EST
- Cc: email@example.com, firstname.lastname@example.org
- In-reply-to: Sandra J Loosemore's message of Mon, 13 Mar 89 16:31:17
Cris perdue was kind enough to send a copy of this proposal to me.
I would like to say that I think that compiler optimizers are an
extremely good idea---right up there with the best of the ideas ever
presented to the committee.
I really hate having to make things macros for trivial reasons,
because this blocks you from funcalling them and using them as
arguments to MAPCAR REDUCE etc. If this mechanism were in Common Lisp
I would use it all the time. I bet it would cover a significant chunk
of what I use macros for.
To be more specific, there are a number of places where such compiler
optimizers would be of HUGE benefit in my portable implementation of
SERIES. In particular, they would be an appropriate framework in
which to state the whole thing. Now, since I have to do it all with
macros, a number of things that should, by every right, be functions
have to be macros instead. This in fact makes it impossible to make an
implementation of what I really want.
Much as I like the proposal, I think there are a couple of places
where it might be improved.
(1) you might consider having OPTIMIZE-EXPRESSION-1 act like
MACRO-EXPAND-1 when given a macro call. Or alternatively, have a
function called OPTIMIZE-OR-EXPAND-EXPRESSION-1. Otherwise, code
walkers are going to have to implement this functionality themselves
since optimizations can expand into macros and vice versa.
(2) The same of course goes for OPTIMIZE-EXPRESSION.
(3) Perhaps the proposal cannot require an implementation to actually
use the optimizers. However, it should certainly encourage
compilers to use them in the strongest possible terms.
(4) I agree that things should be kept simple and not get into pattern
(5) I agree with what Barrett says about the interaction of
inline/noinline and optimizers.
In summary, I recommend the inclusion of this idea in the strongest
possible terms. In particular, although I think the ideas above would
be improvements, I would much rather see the proposal accepted as is
rather than not accepted.