[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Two functions for everything?
- To: SANDRA <LOOSEMORE@UTAH-20.ARPA>
- Subject: Two functions for everything?
- From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
- Date: Mon, 30 Jun 1986 17:40:00 -0000
- Cc: common-lisp@SU-AI.ARPA
- In-reply-to: Msg of 30 Jun 1986 13:09-EDT from SANDRA <LOOSEMORE at UTAH-20.ARPA>
- Sender: FAHLMAN@C.CS.CMU.EDU
It is impossible in a portable language spec to indicate exactly what
opimizations will be be available and how the user will control them.
The nature of these optimizations and the trade-offs they involve will
vary tremendously from one system to another. There are probably
optimzations that we haven't invented yet, but that will be part of
some Common Lisp implementation some day.
If an implementaiton wants to give its users access to all of the
individual policy switches so that they have precise control over which
optimizations are used, that's fine, but it is deeply non-portable.
The OPTIMIZE declaration gives the user a portable way of saying, in
general, what his preferences are. It is up to the implementor of each
system to turn these preferences into reasonable policy decisions, given
his system's particular tradeoffs. These decisions should be documented
for each implementation, but they cannot be standardized in any
meaningful way across very different implementations.
I am a bit skeptical of systems that allow the user to redefine what the
OPTIMIZE declaration does. It seems more tasteful to hard-wire the
optimize-to-policy mapping, but to give the really tense users an
implementation-dependent way to over-ride the OPTIMIZE settings and to
manipulate the individual policy switches directly.
Implementations will vary in how finely they allow the user to control
the degree of error checking, but I hope not too many will take the view
that "having to write error checking code at all is a nuisance". A
little trouble taken by the implementors can save a *LOT* of trouble for
the users later on.