[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
EIEIO and CL
From: |
Chong Yidong |
Subject: |
EIEIO and CL |
Date: |
Fri, 09 Oct 2009 12:51:55 -0400 |
Currently, the EIEIO library requires CL at runtime. This is mainly due
to needing `deftype' and `typep' (EIEIO implements a subset of the CLOS
spec, which demand their existence). If possible, it would be nice to
reduce this to a compile-time dependency, so that loading Semantic or
EDE does not load the CL library.
The `typep' requirement is solvable; the `deftype' requirement is the
more interesting. Currently, eieio-defclass contains this code:
;; When using typep, (typep OBJ 'myclass) returns t for objects which
;; are subclasses of myclass. For our predicates, however, it is
;; important for EIEIO to be backwards compatible, where
;; myobject-p, and myobject-child-p are different.
;; "cl" uses this technique to specify symbols with specific typep
;; test, so we can let typep have the CLOS documented behavior
;; while keeping our above predicate clean.
(eval `(deftype ,cname ()
'(satisfies
,(intern (concat (symbol-name cname) "-child-p")))))
The problem here is that the `cname' argument to the deftype CL macro
is, in general, determined at run-time.
Another possibility is to change eieio-defclass so that it defers this
deftype form till CL is loaded, by putting it on cl-macs-load-hook.
This assumes that the deftype is only useful if some later code calls
typep or typecase; if this assumption is wrong, that could lead to
subtle bugs.
Or, there may be a way to change `deftype' (or to provide a different CL
macro) that can do the right thing at compile-time.
Any suggestions?
- EIEIO and CL,
Chong Yidong <=