2.4.1 File types

',/foolbar". Finally, if pathname b does not have a directory component, the directory component of pathname a becomes c's directory component.

There are several implementation-dependent facets to a COMMON LISP com-piler. These include the naming of source and object files, and how declara-tions are handled and optimizadeclara-tions are performed.

The default source-file type in Tek COMMON LISP is "cI". The default compiled-file type in Tek COMMON LISP is "fas!", which is a mnemonic for 'fast-Ioadable' file. The default source-file type may be changed to suit your preferences.

The variable system:*souree-file-types* is a list of pathname types of COMMON LISp source files. The default value of this variable is ("cI'? This means that if no file type is specified for the argument of compile-file (or the top-level command :cf) the file type "ef" will be assumed. For example

(compile-file "foo")

will cause the compiler to first look for the file joo.cl. If this file is not found, then the compiler will search for joo.1 Some users prefer to use "lisp" as a source file type instead of "ct".

(setq system:*source-file-type* '(flcI" "lisp"))

will cause the compiler to look for files with file type "lisp" as well as "c/".

Then

(compile-file "foo")

will look for joo.el, joo.lisp, and joo in that order, and compile the first file found.

An element of system:*souree-file-types* may be nil, denoting a file name with no type. For example, a value of (nil "cl") will cause (compile-fiJe-if-needed "bar") to look first for bar then for bar.cl.

Users who change system:*souree-fi/e-types* may also wish to change system:*/oad-seareh-/ist* and system:*require-seareh-list* so that the func-tions load and require will look for files with the desired file types as well.

See §3.3, Search lists, for a description of these variables.

I Refer to §2.3, Path names, in this chapter for a description of how Tek COMMON LIsp parses UNIX namestrings and merges UNIX pathnames.

0-01-02(26-11

·86)

Tek COMMON Lisp Implementation 2-5

The compiler generates code which, in addition to carrying out the tasks required by the LISp code, checks that input is of the correct type, allows for profiling and facilitates debugging, and checks for interrupts. This additional code is fast and small, but of necessity somewhat reduces the speed and increases the size of the compiled code. Users can control the amount of this extra code that is produced with the options specified below. The fIrst line of control is to set the safety, size and speed options. The descriptions below show how values of safety, size and speed affect code generation. The values run from 0 to 3 for safety, size and speed, with 0 representing the least concern for safety, size and speed, and 3 representing the greatest concern. The user can control the level of safety, size and speed by using the proclaim function, as follows:

{proclaim '(optimize (safety n1) (size n2) (safety n3)))

where n 1, n2 and n3 are integers from 0 to 3. The following variables define what the various settings of safety, size and speed do. They are bound to func-tions which return t or nil for the given settings of safety, size and speed. Note that with the current definitions, the setting of size does not affect the code generated by the compiler. The user may change the definitions so that size is relevant. The code for changing the settings is given after the definitions.

compiler:declared-fixnums-remain-fixnums-switch [Variable]

• Bound to a function which, given safety, size and speed, returns t if the compiler should assume that the sum and the difference of arguments declared to be fixnums will result in a fixnum. By default, returns t if speed is greater than 2 and safety is less than 2.

compiler:generate-call-count-code-switch [Variable]

• Bound to a function which, given safety, size and speed, returns t if the compiler should generate call-counting code. Call counting is used only by the profiler. Its overhead is small, however, so it is recommended that it be done. By default, returns t unless speed is set to 3.

compiler:generate-interrupt-check-switch [Variable]

• Bound to a function which, given safety, size and speed, returns t if the compiler should generate code to check for asynchronous interrupts (like control-C from the keyboard.) If this check is not made, there is no way to stop LISp and regain control if the program goes into an infinite loop. By default, returns t unless speed is set to 3.

2.4.2

Tektronix, Inc.

2-6 Implementation

compiler:trust-declarations-switch [Variable}

• Bound to a function which, given safety, size and speed, By default, returns t if declarations the user provides should be trusted without verify-ing them at runtime. By default, returns t when speed is greater than safety.

compiler:verify-argument-count-switch [Variable}

• Bound to a function which, given safety, size and speed, returns t if the compiler should generate code to verify that the correct number of argu-ments have been passed to a function. Note: if the wrong number of argu-ments are passed to a function without detection, the consequences can be fatal to LISP. Argument checks are always done if there are &opfional or

&resf arguments. By default, returns t is speed is less than 3 or safety is greater than O.

compiler:verify-car-cdr-switch [Variable}

• Bound to a function which, given safety, size and speed, returns t if the compiler should generate code to verify that the type of an object whose type is undeclared is a list before doing a car or cdr of the object. By default, returns t for speed less than 3 or safety greater than 1.

compiler:verify-non-generic-switch [Variable}

• Bound to a function which, given safety, size and speed, returns t if the compiler should generate code to verify that the type of an object whose type is undeclared is of the correct type when the object appears as an argument to a non-generic function, (e.g. svref). By default, returns t for speed less than 3 or safety greater than 1.

compiler:verify-symbol-value-is-bound-switch [Variable}

• Bound to a function which, given safety, size and speed, returns t if the compiler should generate code to detect that a symbol's value is bound before that value is used. By default, returns t for speed less than 3 or safety greater than 1.

The user may change the safety, size and speed values that trigger these vari-able settings in the following way.

(setq var #'(Iambda (safety size speed) (declare (ignore size)) (logical-form)))

where (logical-form) is nil or t as a function of safety, speed and size.

Tek COMMON LiSp

Implementation 2-7

Thus, if the following code is executed, the compiler will not generate call counting code for speed set greater than 1 of safety set less than 1 or size greater than 1.

(setq compiler:generate-call-count-code-switch

#'(Iambda (safety size speed) (cond ((> speed 1) nil)

(( < safety 1) nil) ((> size 1) nil) (tt))))

Safety, size and speed all have default value 1.

Certain top-level forms are evaluated by the compiler in its execution environ-ment² in addition to being otherwise processed normally. The functions below are all evaluated by the compiler when seen at top level.

make-package in-package shadow

shadowing-import export

unexport use-package unuse-package import

require

In effect the functions above are treated as if they were surrounded by (eval-when (compile eval load) ... ). Among these functions, only require is not explicitly mentioned in § 11.7 of Common Lisp.

Users trying to debug code will often have occasion to look at the stack for recent function calls. There, one may find, instead of

*,

string _2op string _30p

where string is *, +, <, etc. These functions are called for compiler efficiency, and should be interpreted as the functions named by string. Thus, for

2 This is referred to in Comrrwn Lisp as processing the fonn in compile-time-too mode. Cf.

§§11.7 and 5.3.3.

2.4.3 Top-level forms

2.5 Internal functions

Tektronix, Inc.

2-8 Implementation

2.6

A note on