* EIEIO and CL
@ 2009-10-09 16:51 Chong Yidong
2009-10-09 20:05 ` Eric M. Ludlam
0 siblings, 1 reply; 4+ messages in thread
From: Chong Yidong @ 2009-10-09 16:51 UTC (permalink / raw
To: emacs-devel
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?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: EIEIO and CL
2009-10-09 16:51 EIEIO and CL Chong Yidong
@ 2009-10-09 20:05 ` Eric M. Ludlam
2009-10-09 20:36 ` Chong Yidong
0 siblings, 1 reply; 4+ messages in thread
From: Eric M. Ludlam @ 2009-10-09 20:05 UTC (permalink / raw
To: Chong Yidong; +Cc: emacs-devel
On Fri, 2009-10-09 at 12:51 -0400, Chong Yidong wrote:
> 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?
Hi,
The defclass operation in EIEIO is a macro that calls out to a helper
function. This is because I have found that I'm just not that good at
writing macros. I would guess that if the entirety of eieio-defclass
were turned into a macro, then the whole eval thing you quoted above
would become a compile time requirement only. Would it then be a
requirement during compilation of code that uses defclass, as opposed to
a compile time requirement of eieio.el?
Alternately, it would be cool if typep, or something similar was a part
of Emacs core. Wouldn't the widget/custom setup like that?
Eric
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: EIEIO and CL
2009-10-09 20:05 ` Eric M. Ludlam
@ 2009-10-09 20:36 ` Chong Yidong
0 siblings, 0 replies; 4+ messages in thread
From: Chong Yidong @ 2009-10-09 20:36 UTC (permalink / raw
To: eric; +Cc: emacs-devel
"Eric M. Ludlam" <eric@siege-engine.com> writes:
> The defclass operation in EIEIO is a macro that calls out to a helper
> function. This is because I have found that I'm just not that good at
> writing macros. I would guess that if the entirety of eieio-defclass
> were turned into a macro, then the whole eval thing you quoted above
> would become a compile time requirement only.
Yes, that would probably work.
> Alternately, it would be cool if typep, or something similar was a part
> of Emacs core. Wouldn't the widget/custom setup like that?
It's feasible to move typep into core, but deftype involves a layer of
CL-implementation gunk that would need to be cleaned up first; not
feasible for 23.2, I think.
^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: EIEIO and CL
@ 2009-10-09 22:29 S+*n_Pe*rm*n
0 siblings, 0 replies; 4+ messages in thread
From: S+*n_Pe*rm*n @ 2009-10-09 22:29 UTC (permalink / raw
To: Chong Yidong, eric; +Cc: emacs-devel
Doesn't this little bit at the top of cl-macs get you most of the way?
,---- :FILE "/emacs/lisp/emacs-lisp/cl-macs.el"
| ;; This kludge allows macros which use cl-transform-function-property
| ;; to be called at compile-time.
|
| (require
| (progn
| (or (fboundp 'cl-transform-function-property)
| (defalias 'cl-transform-function-property
| (function (lambda (n p f)
| (list 'put (list 'quote n) (list 'quote p)
| (list 'function (cons 'lambda f)))))))
| (car (or features (setq features (list 'cl-kludge))))))
`----
s_P
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-10-09 22:29 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-10-09 16:51 EIEIO and CL Chong Yidong
2009-10-09 20:05 ` 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
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.