[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: OPTIMIZE-SAFETY (Version 1)
- To: CL-Cleanup@SAIL.Stanford.EDU
- Subject: Issue: OPTIMIZE-SAFETY (Version 1)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Mon, 6 Mar 89 17:42 EST
Sorry this is last-minute, but I believe it to be important.
References: OPTIMIZE declaration (p160),
Edit history: 6-Mar-89, Version 1 by Pitman
Status: For Internal Discussion
CLtL permits implementations to ignore OPTIMIZE declarations,
yet the new error terminology has a term ``should signal''
which guarantees that certain errors will be signalled in highest
This situation is at odds with the desire on the part of some vendors
to provide highly delivery configurations for Common Lisp, which
are streamlined to be small and fast at the expense of error checking.
If an implementation is permitted to start out in low safety mode,
and is also permitted to ignore OPTIMIZE SAFETY declarations, then
the meaning of ``should signal'' is called into question.
1. Define the initial safety setting of an implementation's
OPTIMIZE declarations to be implementation dependent. Conforming
implementations must document the initial setting.
2. Require every implementation to do at least one (and possibly
both) of the following:
a. Start in highest safety mode.
b. Not ignore the OPTIMIZE declaration.
Put another way, an implementation implementation which starts
out in ``unsafe'' mode is prohibited from ignoring OPTIMIZE
declarations that would allow the programmer to declare code
to require ``safe'' treatment.
1. This allows a particular implementation (or a particular core-image
that is part of an implementation family) to be naturally biased
2. This makes sure that situations like
(LOCALLY (DECLARE (OPTIMIZE (SPEED 0) (SAFETY 3)))
will reliably select "safe code" even in implementations that are
initially biased for speed over safety.
Symbolics Genera and Symbolics Cloe conform to the stated proposal.
Cost to Implementors:
Considerable error checking would have to be added to upgrade any
non-conforming implementations, if in fact there are any.
Another alternative would be for a non-conforming implementation to
identify itself as a special "subset" of Common Lisp that does not
support those options. That would require no work, but would require
careful documentation in order for users to understand the consequences.
However, such a subset could easily notice when the programmer was
trying to enter a high safety mode explicitly, and could warn that he
was probably going to lose.
Cost to Users:
None. Most users will regard this as a bug fix.
Cost of Non-Adoption:
Any useful interpretation of ``should signal'' will be in severe
More truth in packaging.
Adding this kind of reliability presumably improves aesthetics.
Pitman supports this proposal.