[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: LOAD-OBJECTS (Version 3)
- To: sandra%defun@cs.utah.edu
- Subject: Issue: LOAD-OBJECTS (Version 3)
- From: jrose@Sun.COM (John Rose)
- Date: Mon, 13 Mar 89 11:35:38 PST
- Cc: rpg@lucid.com, CL-Cleanup@sail.stanford.edu, CL-Compiler@sail.stanford.edu, Common-Lisp-Object-System@sail.stanford.edu
- In-reply-to: Sandra J Loosemore's message of Sat, 11 Mar 89 18:42:56 MST <8903120142.AA00878@defun.utah.edu>
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Date: Sat, 11 Mar 89 18:42:56 MST
...
Have two generic functions, not one. The first would get called by
compile-file and it would return a list of components (or whatever)
that are required to reconstruct the object. The compiler would dump
this list of objects in its usual way. The loader would apply the
second generic function to this list to reconstruct the object. It
avoids the nasty syntax you object to, doesn't require functions to be
dumpable, doesn't require any special support for circular constants,
and ought to be real easy to add to the compiler/loader. (You could
essentially convert the constant into a LOAD-TIME-VALUE expression.)
Two objections here:
One is that this scheme cannot support circular constants. Since
LOAD-OBJECTS is not the issue which determines circular constants, it
probably should not force or presuppose a decision against circular
constants.
Supporting circular constants requires two phases of object
construction, one which creates at least a valid reference to the
object, and a second one which further initializes the object (at least
by patching in back-references to finish building circularities).
In order for your technique to support circular constants, you still
need #'make-load-form to return two things, not one. It would return
two argument lists, and there would be two load-time generic functions.
The other objection is that an arglist for a fixed generic function is
less general and more complex than an EVAL-able form (or a thunk, as rpg
suggests). The programmer must coordinate the construction of the
argument list with the definition of the method to digest it at load
time, which is probably on a different page of the source code. What's
the advantage to offset the complexity and lack of flexibility?
Perhaps method combination within the load-time generic gives a clean
way to modularize the construction of an object of multiple classes?
Someone will have to show me an example of this before I believe it.
Until then, I think the simplicity of thunks (either EVAL-able or
FUNCALL-able) is far preferable.
By the way, I also share rpg's preference for functions over forms,
because functions are parametrized naturally via captured lexicals,
whereas you've got to use backquote to parametrize forms, a more
error-prone technique.
Here's an example which suggests the relative conciseness of the techniques:
;; Using functions:
(defmethod make-load-form ((x myclass))
(let ((p <pval>) (q <qval>) (r <rval>))
#'(lambda () <code>)))
;; Using forms:
(defmethod make-load-form ((x myclass))
`(let ((p ',<pval>) (q ',<qval>) (r ',<rval>))
<code>))
;; Using a generic:
(defmethod make-load-form ((x myclass))
`(cookie00012 :p ,<pval> :q ,<qval> :r ,<rval>))
(defmethod load-time-constructor
((lf (eql 'cookie00012)) &key p q r &allow-other-keys)
<code>)
-Sandra
-------
-- John