From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric M. Ludlam" Newsgroups: gmane.emacs.devel Subject: Re: EIEIO and CL Date: Fri, 09 Oct 2009 16:05:40 -0400 Message-ID: <1255118740.6961.443.camel@projectile.siege-engine.com> References: <87ocogtsr8.fsf@stupidchicken.com> Reply-To: eric@siege-engine.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1255118742 6154 80.91.229.12 (9 Oct 2009 20:05:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 9 Oct 2009 20:05:42 +0000 (UTC) Cc: emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 09 22:05:29 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MwLiS-0000JF-Ue for ged-emacs-devel@m.gmane.org; Fri, 09 Oct 2009 22:05:29 +0200 Original-Received: from localhost ([127.0.0.1]:36006 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MwLiS-0007UV-9p for ged-emacs-devel@m.gmane.org; Fri, 09 Oct 2009 16:05:28 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MwLiL-0007UD-Rc for emacs-devel@gnu.org; Fri, 09 Oct 2009 16:05:21 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MwLiJ-0007Th-VS for emacs-devel@gnu.org; Fri, 09 Oct 2009 16:05:21 -0400 Original-Received: from [199.232.76.173] (port=48032 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MwLiJ-0007Te-Qq for emacs-devel@gnu.org; Fri, 09 Oct 2009 16:05:19 -0400 Original-Received: from static-71-184-83-10.bstnma.fios.verizon.net ([71.184.83.10]:54969 helo=projectile.siege-engine.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MwLiJ-00066B-AC for emacs-devel@gnu.org; Fri, 09 Oct 2009 16:05:19 -0400 Original-Received: from projectile.siege-engine.com (localhost [127.0.0.1]) by projectile.siege-engine.com (8.14.3/8.14.3/Debian-6) with ESMTP id n99K5e6H008411; Fri, 9 Oct 2009 16:05:40 -0400 Original-Received: (from zappo@localhost) by projectile.siege-engine.com (8.14.3/8.14.3/Submit) id n99K5eLr008410; Fri, 9 Oct 2009 16:05:40 -0400 X-Authentication-Warning: projectile.siege-engine.com: zappo set sender to eric@siege-engine.com using -f In-Reply-To: <87ocogtsr8.fsf@stupidchicken.com> X-Mailer: Evolution 2.26.1 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:116030 Archived-At: 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