From: Chong Yidong <cyd@stupidchicken.com>
To: emacs-devel@gnu.org
Subject: EIEIO and CL
Date: Fri, 09 Oct 2009 12:51:55 -0400 [thread overview]
Message-ID: <87ocogtsr8.fsf@stupidchicken.com> (raw)
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?
next reply other threads:[~2009-10-09 16:51 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-09 16:51 Chong Yidong [this message]
2009-10-09 20:05 ` EIEIO and CL Eric M. Ludlam
2009-10-09 20:36 ` Chong Yidong
-- strict thread matches above, loose matches on Subject: below --
2009-10-09 22:29 S+*n_Pe*rm*n
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ocogtsr8.fsf@stupidchicken.com \
--to=cyd@stupidchicken.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.