Using OpenMCL in "development" and in "user" mode


Table of Contents

Overview
Functional Reference
*warn-if-redefine-kernel* [Special Variable]
set-development-environment [Function]
set-user-environment [Function]
Discussion

Overview

OpenMCL has traditionally been released with settings that make it convenient to do development of OpenMCL itself; sometimes, those settings make it less convenient to use OpenMCL for development or deployment of other software.

Specifically, OpenMCL has been released with (IN-PACKAGE "CCL") in effect, and with no protection against inadvertent redefinition of builtin, predefined functions and methods. The former behavior isn't correct (though it's often expedient); the latter behavior (and especially the two in conjunction) can be dangerous.

Beginning with release 0.11, OpenMCL comes up in the CL-USER package and protects all functions and methods in the initial image from accidental redefinition. (Attempts to redefine a predefined function or method result in a continuable error.)

These settings may make using OpenMCL to develop OpenMCL a bit more awkward, since much of that process assumes that the CCL package is current (and a primary purpose of that process is to redefine some "predefined, builtin functions".) The standard, "routine" ways of Building OpenMCL from sources - COMPILE-CCL, XCOMPILE-CCL, and XLOAD-LEVEL-0 - bind *PACKAGE* to the "CCL" package and enable the redefinition of predefined functions; the symbols COMPILE-CCL, XCOMPILE-CCL, and XLOAD-LEVEL-0 are additionally now exported from the "CCL" package.

Some other (more ad-hoc) ways of doing development on OpenMCL - compiling and/or loading individual files, incrementally redefining individual functions - may be awkward unless one reverts to the mode of operation which was traditionally offered in OpenMCL. (Some OpenMCL source files - especially those that comprise the bootstrapping image sources and the first few files in the "cold load" sequence - are compiled and loaded in the "CCL" package but don't contain (IN-PACKAGE "CCL") forms, since IN-PACKAGE doesn't work until later in the cold load sequence.)

Functional Reference

*warn-if-redefine-kernel* [Special Variable]

Description

When true, attempts to redefine (via DEFUN or DEFMETHOD) functions and methods that are marked as being "predefined" signal continuable errors.

Note that these are CERRORs, not warnings, and that no lisp functions or methods have been defined in the kernel in MCL or OpenMCL since 1987 or so.

set-development-environment [Function]

Syntax

set-development-environment &optional unmark-builtin-functions

Description

Arranges that the outermost special bindings of *PACKAGE* and *WARN-IF-REDEFINE-KERNEL* restore values of the "CCL" package and NIL to these variables, respectively. If the optional argument is true, marks all globally defined functions and methods as being "not predefined" (this is a fairly expensive operation.)

set-user-environment [Function]

Syntax

set-user-environment &optional mark-builtin-functions

Description

Arranges that the outermost special bindings of *PACKAGE* and *WARN-IF-REDEFINE-KERNEL* restore values of the "CL-USER" package and T to these variables, respectively. If the optional argument is true, marks all globally defined functions and methods as being "predefined" (this is a fairly expensive operation.)

Discussion

The somewhat bizarre behavior of both SET-USER-ENVIRONMENT and SET-DEVELOPMENT-ENVIRONMENT with respect to the special variables they affect is intended to allow those constructs to take effect when the read-eval-print loop next returns to a top-level '? ' prompt; the constructs can meaningfully be used inside LOAD, for instance (recall that LOAD binds *PACKAGE*), though using both constructs within the same LOAD call would likely be pretty confusing.

"user" and "development" are otherwise very generic terms; here they're intended to enforce the distinction between "using" OpenMCL and "developing" it.

The initial environment from which OpenMCL images are saved is one where (SET-USER-ENVIRONMENT T) has just been called; in previous versions, it was effectively as if (SET-DEVELOPMENT-ENVIRONMENT T) had just been called.

Hopefully, most users of OpenMCL can safely ignore these issues most of the time. Note that doing (SET-USER-ENVIRONMENT T) after loading one's own code (or 3rd-party code) into OpenMCL would protect that code (as well as OpenMCL's) from accidental redefinition; that may be useful in some cases.