From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: EIEIO and CL Date: Fri, 09 Oct 2009 12:51:55 -0400 Message-ID: <87ocogtsr8.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1255107354 1698 80.91.229.12 (9 Oct 2009 16:55:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 9 Oct 2009 16:55:54 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 09 18:55:47 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 1MwIkl-0005DV-SR for ged-emacs-devel@m.gmane.org; Fri, 09 Oct 2009 18:55:40 +0200 Original-Received: from localhost ([127.0.0.1]:41012 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MwIkk-00039Y-US for ged-emacs-devel@m.gmane.org; Fri, 09 Oct 2009 12:55:39 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MwIhH-0001mc-JX for emacs-devel@gnu.org; Fri, 09 Oct 2009 12:52:03 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MwIhC-0001je-E7 for emacs-devel@gnu.org; Fri, 09 Oct 2009 12:52:02 -0400 Original-Received: from [199.232.76.173] (port=36747 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MwIhB-0001jT-Vr for emacs-devel@gnu.org; Fri, 09 Oct 2009 12:51:58 -0400 Original-Received: from pantheon-po39.its.yale.edu ([130.132.50.100]:54237) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MwIhB-0008Rb-IL for emacs-devel@gnu.org; Fri, 09 Oct 2009 12:51:57 -0400 Original-Received: from furry (dhcp128036014244.central.yale.edu [128.36.14.244]) (authenticated bits=0) by pantheon-po39.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id n99Gpus1003264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 9 Oct 2009 12:51:56 -0400 Original-Received: by furry (Postfix, from userid 1000) id 9F824C070; Fri, 9 Oct 2009 12:51:55 -0400 (EDT) X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 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:116019 Archived-At: 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?