More eval-when madness. Suppose I have these macros:
(defmacro define-type-conversion (name (value) &body body)
(let ((function-name (make-symbol (format nil "~a~a" 'convert-to- (string name)))))
`(progn
(eval-when (:compile-toplevel :load-toplevel :execute)
(setf (get ',name 'conversion-function) ',function-name))
(defun ,function-name (,value)
,@body))))
(defmacro call-type-conversion (type value)
`(,(get ',type 'conversion-function) ,value))
The idea is that one can use define-type-conversion in a a file and
later in that same file use call-type-conversion with the previously
defined type. My theory is the uninterned symbol used as the name of
the conversion function that is created at compile time is stashed in
the evaluation environment where it will be available to the
call-type-conversion macro expansion function.
But then I started thinking about what happens when the compiled
function is loaded. I think with just these two macros it still works
fine--I assume based on the definition of "similarity" for symbols
that all occurences of this uninterned symbol in the fasl file will be
mapped to the same symbol object in the run-time environment when the
fasl is loaded. Is that right?
Then I thought of another wrinkle: what if I also define these macros:
(defmacro define-foo-conversion (name (value) &body body)
(let ((function-name (make-symbol (format nil "~a~a" 'convert-to- (string name)))))
`(progn
(eval-when (:compile-toplevel :load-toplevel :execute)
(setf (get ',name 'foo) ',function-name))
(defun ,function-name (,value)
,@body))))
(defmacro call-foo-conversion (type value)
`(,(get ',type 'foo) ,value))
and then compile a file that contains:
(define-type-conversion bar (value) (somethnig value))
(define-foo-conversion bar (value) (something-else value))
(defun quux ()
(list (call-type-conversion "xxx")
(call-foo-conversion "yyy")))
After I COMPILE-FILE that file and LOAD it am I guaranteed that the
two #:CONVERT-TO-BAR symbols are still distinct objects?
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> writes:
> More eval-when madness. Suppose I have these macros:
Bah, never mind. I thingk figured this one out myself. Since the file
compiler (per 3.2.4.4) is guaranteed to preserve EQLness all
references to the same uninterned symbol in the source code will be
references to the same uninterned symbol in the compiled code. And
because symbols (and packages) are explcitly excluded from the list of
types that can have "similar" objects coalesced I don't have to worry
about non-EQL symbols in the source code being coalesed in the
compiled code.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp