salewski / cl-policy-cond Goto Github PK

                             POLICY-COND
                             ===========

                           By Robert Smith

License
-------

This software is licensed under BSD 3-clause license. Please see LICENSE.


Environment Introspection
-------------------------

This library provides an interface to the CLtL2 environment
functions. Currently, only DECLARATION-INFORMATION is supported.


Temporarily Setting and Restoring Optimize Policy
-------------------------------------------------

One can use WITH-POLICY to temporarily set the global optimize policy
for e.g. loading systems. The original policy will be restored upon
completion.

WITH-POLICY should not be used with local declarations. In that case,
one should use LOCALLY.


Expansion Based on Policy
-------------------------
                           
POLICY-COND is a macro in order to select certain code paths based on
the current optimize compiler policy.

For example, given the following code:

(declaim (optimize (speed 0) (safety 3)))

(defun test-cond ()
  (policy-cond
    ((> speed safety) (+ 1 1))
    ((= speed safety) (+ 2 2))
    ((< speed safety) (+ 3 3))))

The function TEST-COND will get compiled as if it were

(defun test-cond ()
  (+ 3 3))

The optimize qualities SPEED, SAFETY, SPACE, DEBUG, and
COMPILATION-SPEED are guaranteed by an implementation. They can be
used as if they are lexically bound.

Currently, any expression for the policy expression can be used. In
the future, this might change to a limited set of operators.

Also included is POLICY-IF which behaves much like POLICY-COND, except
is akin to CL:IF.

Finally there is another package, POLICY, which exports IF, which is
intended to be used with reader macros. For example,

    #+#.(policy:if (<= speed safety)) (safe-algorithm)

Note that this does not work with local declarations. See

    http://clhs.lisp.se/Body/s_declar.htm#declare

for details.


Expectations
------------

An "expectation" is something the programmer expects to be true, but
could be wrong if the consumer of the code makes a logical
error. Expectations usually have different behavior in testing and
production environments. When testing, it is permitted that code be
slower due to sanity checking, and in production (after considerable
testing), it may make sense to remove extra sanity checking and add
speed improvements.

POLICY-COND offers the notion of an expectation, which can change with
policy. The macro POLICY-COND:WITH-EXPECTATIONS accomplishes this. It
is best described with an example.

    (defun vector-item (vec n)
      (with-expectations (> speed safety)
          ((type unsigned-byte         n)
           (type (vector single-float) vec)
           (assertion (< n (length vec))))
        (aref vec n)))

If the policy expression is not satisfied, then it will expand into

    (PROGN
      (CHECK-TYPE N UNSIGNED-BYTE)
      (CHECK-TYPE VEC (VECTOR SINGLE-FLOAT))
      (ASSERT (< N (LENGTH VEC)))
      (AREF VEC N))

But if it is satisfied, it will expand into

    (LOCALLY (DECLARE (TYPE UNSIGNED-BYTE N)
                      (TYPE (VECTOR SINGLE-FLOAT) VEC))
      (AREF VEC N))

In other words, we can read

    (with-expectations POLICY (EXPECTATIONS...) BODY...)

as

    "With the expectation that EXPECTATIONS are met when POLICY is
    true, execute BODY. Otherwise, ensure that they're true."

See the documentation string for WITH-EXPECTATIONS to see the kinds of
expectation clauses supported.


See Also
--------

For similar functionality for static function dispatch, see:

    https://bitbucket.org/tarballs_are_good/parameterized-function