3 Predefined variables

There is a function safe!-fp!-plus that performs floating point arithmetic but guarantees never to raise an exception. This value was at one stage related to when small values created there got truncated to zero, but the current code does not use the Lisp variable at all and instead does things based on the bitwise representation of the numbers.
See !@cslbase.
The value of this variable is a pseudo-character returned from various read functions to signal end-of-file.
The value of this variable is an end-of-line character.
If this is set it might be supposed to be the name of a function used by the interpreter as a callback, but at present it does not actually do anything!
If the value of this is a symbol that is defined as a function of one argument then it is called during the processing on an error. This has not been used in anger and so its whole status may be dubious!
In general CSL arranges that every car or cdr access is checked for validity. Once upon a time setting this variable to nil turned such checks off in the hope of gaining a little speed. But it no longer does that. It may have a minor effect on array access primitives.
When set each function is compiled (into bytecodes) as it gets defined.
An I/O channel intended to be used for diagnostic interactions. The concept and name is taken from Common Lisp, but there is in fact no real separation between this and the standard input and output streams.
When this is non-nil characters that are read from an input file are echoed to the standard output. This gives a more comlete transcript in a log file, but can sometimes amount to over-verbose output.
Has the value nil and does not do anything! At one stage the idea had been that CSL’s error messages would be in this table so as to be available from Lisp, but that never happened.
An I/O channel intended for diagnostic output. The concept comes from Common Lisp but Standard Lisp (and hence CSL) does not really exploit it.
See !*applyhook!*. This also does not do anything at present, but it it did it would be a place to put the name of a function that would be called by the interpreter when applying a function.
If this is set to have as its value that is a function of one argument then that function is called with nil on every minor entry to the garbage collection, and with argument t at the end of a “genuine” full garbage collection. This may sometimes be of interest for those who want to notice when garbage collection happens but want to control how they are informed rather than relying on the displayed text that the verbos function controls.
This was concerned with internationalisation to support a Japanese locale but has not been activated for some while. In the fullness of time I hope to migrate CSL to use an UTF8 representation of Unicode characters internally, but that upgrade is at present an ideal and a project not a reality. Volunteers to help welcome!
In CSL if the fluid variable !*lower is set (which it is by default) then when characters are read they are folded to lower case. The related variable !*raise causes input to be folded to upper case on input. In the original Standard Lisp the true internal names of all functions were in upper case, and !*raise was used so that code using it could be written in mixed or lower case. At some stage it was accepted that upper case was a throw-back to the days of FORTRAN and punched cards, so the CSL switched to using lower case internally and the !*lower flag allowed the existing Reduce sources to survive. At some time in the future I hope that Reduce will arrange to have both *raise and !*lower set to nil so that it becomes a case-sensitive system.

Note that the PSL Lisp system once (but not now) used !*lower to cause internally upper case symbols to be printed in lower case, so that there it is a control of output rather than input case folding. PSL has functions input!-case and output!-case that are relevant in this respect. So code that is to be portable between the two Lisps needs to take care.

Common Lisp would like it to be possible to specify a function that would be called to allow overriding of the normal method of expanding macros. This variable exists in CSL in case at any stage a serious need for this capability arises, but at present any use of this variable has no effect.
In the case that CSL is being used with Reduce and its “fancy” maths mode display is available in a GUI then this provides a special output stream that displayable layout information in a TEX-like notation that is not documented here because it is potentially in the process of being updated. The tmprint package in Reduce generates this material and collaborates with the mathematical display parts of CSL.
An experimental additional compiler for CSL that maps Lisp directly onto native code for the current platform has been in development for some time, but it is not in a state such as to make it useful for other than people who wish to experiment, extend and debug it. This flag is to do with enabling it. It is not supported but may possibly become so one day.
The CSL compiler normally tries to detect patterns of recursion that it can convert into iteration. This can dramatically reduce stack use and so allow calculations to succeed when otherwise they would have failed. This flag can disable that optimisation. The most plausible reason to want to do that would be if there was serious cause to believe that the code performorming the optimisation was faulty, and results without it were needed as part of the process of tracking down the bug.
Interrnally CSL stores the table that maps names into symbols in a way following the style of the Common Lisp package system. When used as a Standard Lisp there is only one package and no distinction between internal and external name visibility, but this name provides access to the main tdata-structure involved. It is in general expected that this will be used via the oblist function, not directly be users.
See !*plap.
When the CSL compiler runs to generate byte-codes if !*plap or !*pgwd is set then the generated code is displayed. This may be of interest when debugging or for anybody who wants to explore the Lisp bytecode model that is used. If at some stage a full native compiler is released then !*plap will control display of any intermediate Lisp-specific material and !*pgwd will control display of the final generated platform dependent machine code.
The prettyprint function displays a Lisp expression neatly indended. If this variable is set (which by default it is) symbols and strings are shown with escape characters and quotation marks so that the indented form could be re-input. If this variable is set to nil that does not happen – the output may not be re-readable by CSL but in some cases it may be easier for a human reader to decipher.
Used internally by the functions prinl and princl that can print data structures that are re-entrant or looped. Not for use by end-users.
Used internally by the functions prinl and princl that can print data structures that are re-entrant or looped. Not for use by end-users.
Used internally by the functions prinl and princl that can print data structures that are re-entrant or looped. Not for use by end-users.
In prinl if this variable is nil arrays and structures are not printed in full. In some cases this merely loses valuable information, while in others it leads to output that is more concise and legible and hence nore useful.
In prinl if this variable is set to an integer then that specifies the largest number of items in a list that will be displayed.
In prinl if this variable is set to an integer then that specifies the greatest depth of nesting of lists before the printing gives up. This and !*print!-length!* may very occasionally be useful when faced with huge lists of whihc only the top few layers are relevant.
This is normally set, and it causes the compiler to display a message commenting on how many bytes were used in the compiled version of each function that is processed.
An I/O channel intended to be used for query interactions. The concept and name is taken from Common Lisp, but there is in fact no real separation between this and the standard input and output streams.
Used in the prettyprinter to determine whether the form (quote x) should be displayed as ’x. By default it is.
See !*lower.
If this is set a message is displayed when a function is redefined.
See the resource!-limit function.
If this variable is set then when you define a function and compile it the original interpratable Lisp form of the defintion is saved under the property-name !*savedef so that it could be recovered using get. If the function is being compiled into a fasl-file for later reloading the lisp form of the definition is saved there so that when load!-module or load!-source is used it can be retrieved. This facility is activated when the “bootstrap” version of Reduce is built so that in effect the full source code is available at run-time. The availability of source in that way can be useful for forms of global analysis or optimisation of the code – for instance Reduce uses it to find the definitions of functions that it wants to optimise int C code rather than the slower (but more compact) bytecodes it uses for most things.
The spool function or the command-line option -l can establish a file that normal output is copied to as a log. This variable holds a handle to that file.
Standard Lisp specifies that to select input from the “standard” source one goes (rds nil). In CSL this is underpinned by having an input stream as stored in this variable following the naming convention used by Common Lisp.
As !*standard!-input!* but for output.
A Common Lisp motivated variable which is intended to provide access to the “terminal”. In Standard Lisp you are expected to use rds and the precise concept of a terminal is not really defined.
The Lisp trace facility tends to send output to this which is a synonym for the original standard output.
This variable is not actually predefined, but I will nevertheless give some explanation of how it is used during the bootstrapping process that makes a CSL or a Reduce image. When you attempt to open a file you mau give a path starting with an initial “$word/…” or “${word}/…”. these notations of course model typical Unix-style parameter substitution. The expansion proceeds by first checking if a Lisp variable “@word” exists with a string or a symbol as its name. If so that value is used as the expansion. If that scheme fails the system next looks for an environment variable and uses its value. This the use of a Lisp variable “@word” takes priority over the system environment. Finally if there is no environment variable available a Lisp variable with name “$word” is checked and if its value is a string or symbol that is the expansion, otherwise the expansion will be empty.

This is used in the build sequences by passing a command-line option -D@cslbase=... that predefines @cslbase to refer to a key directory where necessary files can be found. By defining this rather than $cslbase there is no chance that any odd values in the (shell) environment will cause trouble, and the lines such as (rdf "$cslbase/compat.lsp") can appear in the build code without any need for absolute path names or any reliance on the setting of a current directory.

In a file-name a path that starts with !~/ or !~name/ tries to identify the home directory of the current or named user.

The value of this variable is an space or blank character. This might otherwise be written as ”! ”.
The value of this variable is a carriage-return character that could arise in DOS-format files.
The CSL Lisp system was designed so that if necessary much of the code could be shared with a version that met the Common Lisp Standard. At no stage has there been anything like a complete Common version. This is both because the main use of CSL has been to support Reduce and that wants Standard (not Common) Lisp, and because providing complete support for all the functionality in Common Lisp would be a lot of work and would tend to make the code bulkier (and hence necessarily less reliable) and slower. However various key underpinnings for Common Lisp are present in the C-coded sources, generally guarded by “#ifdef COMMON”. If the Lisp has been built in this way then this variable will be set in order that users can readily detect the situation. At one stage the Axiom algebra system could be built using the limited Common Lisp compatibility mode, but the recent Open Source versions of Axiom have probably changed leaving that not an easy option.
This is a variable used by the Reduce parser, and as a matter of caution it is to be treated as reserved in the Lisp system.
After a call (error nn msg) this variable gets set to the value of the second argument (msg). This may help if you have had a failure and want to see if it resulted from a call to the error function and if so what message had been used with it!
Used in Reduce in association with detecting and handling end-of-file conditions, and reserved in the Lisp to avoid potential interference with that.
The value of this variable is the character “escape”. As a non-printing character use of this is to be viewed as delicate.
This variable is initialised at the start of any run of Lisp to hold information about the computer in use and the collection of features available in the Lisp. The items that might be present are explained further in Section 4.
The function load!-source will load data from a fasl file and is intended to make it possible to have saved uncompiled Lisp forms for functions there – and to be able to reload then in a selective way. The load!-source variable can tune this behaviour. See the explanation of the function for further details.
nil is the fundamental Lisp atom used to stand for “false”, used to terminate lists and generally something that every Lisp programmer will already understand about. In Standard Lisp nil is a symbol and as such you may not take car or cdr of it. So any code that had been developed for Common Lisp and relies on being able to treat it as if it was a non-empty list will need revision. CSL always checks for valid access so not only would (car nil) be a mistake, but any attempt to do it will lead to an exception being raised. nil must not be used as a name of an argument or a prog variable or in any other context that could attempt to alter its value.
Used in Reduce in association with tracking output files, and reserved in CSL to avoid conflict with that.
Used by the Reduce parser to hold a command that has just been parsed, and reserved in CSL in order to ensure that there is no conflict with that.
Used internally by the prettyprint function.
Used internally by the prettyprint function.
Used internally by the prettyprint function.
internal variable used by dated!-name.
Used internally by the prettyprint function.
Used internally by the prettyprint function.
Used internally by the prettyprint function.
Used internally by the prettyprint function.
Used internally by the prettyprint function.
Used internally by the prettyprint function.
Used internally by the prettyprint function.
Used internally by the prettyprint function.
The Lisp value that stands for “true”. Any attempt to reset or rebind t will be an error. The value of t is itself. Yoy may recall that in Lisp 1.5 the value of t had been *t*, but Standard Lisp mandates the behaviour implemented here. As far as truth values are concerned, nil is treated as meaning “false” and anything that is non-nil is true, including as an obvious special case t.
The value of this variable is a tab character.
In the prettyprinter if thin!* values (default 5) can be fitted on a single line. The idea behind this is so that long lists can in relevant cases be displayed almost horizontalloy rather than vertically, as in
  (one two three four five             (one  
   six seven eight nine ten   vs.       two  
   eleven twelve)                       three  

Used by the Reduce parser, and so best not used for other purposes.

Services provided by