From: Nathan T. <nb...@nb...> - 2014-03-02 13:34:24
|
> (funcall (lambda () (declare (special var)) var)) ==> ERROR > (declaim (optimize (safety 0))) > (funcall (lambda () (declare (special var)) var)) ==> #<unbound marker {51}> ;; a true value, btw If this is the intended behavior, I don't see where it's documented. Verified on 1.1.16 and 1.1.15 x86-64 builds on Linux. |
From: Nikodemus S. <nik...@ra...> - 2014-03-06 20:43:13
|
On 2 March 2014 15:07, Nathan Trapuzzano <nb...@nb...> wrote: > > (funcall (lambda () > (declare (special var)) > var)) > ==> ERROR > > > (declaim (optimize (safety 0))) > > (funcall (lambda () > (declare (special var)) > var)) > ==> #<unbound marker {51}> ;; a true value, btw > > If this is the intended behavior, I don't see where it's documented. Absolutely intentional. This is just the sort of stuff you opt in for when you request SAFETY 0. CLHS: >From 1.4.2 Error Terminology http://www.lispworks.com/documentation/HyperSpec/Body/01_db.htm * Safe code This is code processed with the safety optimization at its highest setting (3). safety is a lexical property of code. The phrase ``the function F should signal an error'' means that if F is invoked from code processed with the highest safety optimization, an error is signaled. It is implementation-dependent whether F or the calling code signals the error. * An error should be signaled This means that an error is signaled in safe code, and an error might be signaled in unsafe code. Conforming code may rely on the fact that the error is signaled in safe code. Every implementation is required to detect the error at least in safe code. When the error is not signaled, the ``consequences are undefined'' (see below). For example, ``+ should signal an error of type type-error if any argument is not of type number.'' >From 3.1.2.1.1 Symbols as Forms http://www.lispworks.com/documentation/HyperSpec/Body/03_abaa.htm An error of type unbound-variable should be signaled if an unbound variable is referenced. => no error is required in unsafe code, which SAFETY 0 most assuredly is. If you read above carefully, the standard doesn't actually guarantee an error will be signaled unless you request SAFETY 3 -- but for SBCL anything above 0 should provide that: it treats anything above 0 as "mostly safe". The exact behavior is not exactly documented except for type checking: http://www.sbcl.org/manual/index.html#Declarations-as-Assertions ...but yes, at SAFETY 0 the gloves are off and the house is doused in gasoline. Using SAFETY 0 is almost always the wrong thing. Cheers, -- nikodemus |