[Openmcl-devel] init-file mechanism cleanup?
svspire at sandia.gov
Tue May 17 00:45:36 CDT 2011
I'd like to discuss the init-file mechanism in CCL and suggest an alternative to the current mechanism.
The current mechanism for specification of init-files in CCL is a mess:
-- It's inconsistent between #'save-application and #'build-application and the various application classes.
-- There are at least a couple of different ways to override it, some of which work as expected
and others of which don't.
Typically init-files are defined in an explicit method on the application class. This means that it's not easy to change them dynamically when doing a save-application.
The way #'save-application handles init-files now is to bind the arg in a closure that calls #'toplevel-function. That's not particularly bad, except that that mechanism is ignored if the user specifies a toplevel-function.
Worse, there are four different methods for toplevel-function, and all but one ignore the init-file argument. The one for cocoa-application is one of the methods that ignores it. Yet cocoa-applications actually pay attention to the init-file, and they don't allow you to override it (because of the way #'new-cocoa-listener-process works).
There is a variable called *load-lisp-init-file* which the #'toplevel-function method on lisp-development-system pays attention to but nobody else does. Most notably, #'new-cocoa-listener-process doesn't pay attention to it.
#'build-application doesn't even take an init-file argument. That's easy to fix, but even if you specify an argument to #'build-application such that it passes it to #'save-application, the :init-file arg is ignored. Why? Because #'new-cocoa-listener-process makes its own, separate decision about the init-file.
Here's my proposed solution to all this.
Modify #'build-application so it takes an :init-file argument.
Remove the init-file argument from all #'toplevel-function methods. All but one are
already ignoring it.
Change the #'toplevel-function method on lisp-development-system to do
(startup-ccl (ccl::application-init-file ccl::*application*))
(startup-ccl (and *load-lisp-init-file* init-file))
as it does now.
Keep the init-file argument to #'startup-ccl.
Leave #'new-cocoa-listener-process alone, since it's doing things right.
Add a slot called init-file to application class with an accessor called application-init-file. When an init-file is explicitly specified to #'save-application or #'build-application, stick it into the init-file slot of the application object rather than juggling it lexically.
Remove existing methods on #'application-init-file.
Add appropriate :initforms for the :init-file slot to class application.
Add two :around methods on application-init-file to wit:
(defmethod ccl::application-init-file :around ((a cocoa-application))
(defmethod ccl::application-init-file :around ((a application))
-- The old init-file behavior still works -- and works more consistently:
If *load-lisp-init-file* is nil, no init-file is loaded under any circumstances.
If *load-lisp-init-file* is true but the shift key is held down as a cocoa-application
starts, no init-file is loaded.
-- #'build-application now takes an :init-file arg like #'save-application, and it actually works.
-- It becomes easy to change an init file on the fly just by changing the slot value of
the init-file slot in the application object.
What to do about *ccl-ide-init-file*?
Comments about this proposal?
More information about the Openmcl-devel