From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] trunk r116995: cl-lib defstruct introspection Date: Mon, 21 Apr 2014 18:03:18 -0400 Message-ID: References: <53555822.3080007@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1398117829 11179 80.91.229.3 (21 Apr 2014 22:03:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Apr 2014 22:03:49 +0000 (UTC) Cc: emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 22 00:03:42 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WcMJQ-0004kA-Tf for ged-emacs-devel@m.gmane.org; Tue, 22 Apr 2014 00:03:41 +0200 Original-Received: from localhost ([::1]:51742 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WcMJQ-0006f7-Ed for ged-emacs-devel@m.gmane.org; Mon, 21 Apr 2014 18:03:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35167) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WcMJG-0006ap-Cn for emacs-devel@gnu.org; Mon, 21 Apr 2014 18:03:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WcMJ8-0001Zc-O3 for emacs-devel@gnu.org; Mon, 21 Apr 2014 18:03:30 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:49990) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WcMJ8-0001ZP-I5 for emacs-devel@gnu.org; Mon, 21 Apr 2014 18:03:22 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s3LM3II4018636; Mon, 21 Apr 2014 18:03:19 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 6EDCC600CA; Mon, 21 Apr 2014 18:03:18 -0400 (EDT) In-Reply-To: <53555822.3080007@dancol.org> (Daniel Colascione's message of "Mon, 21 Apr 2014 10:40:50 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4919=0 X-NAI-Spam-Version: 2.3.0.9378 : core <4919> : inlines <751> : streams <1164208> : uri <1736716> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:171549 Archived-At: > That's new. Using the whole ChaneLog message has been a recommendation, > but never a requirement. For `elpa', that's true, but for `emacs' it's always been a requirement, on the premise that this should/will allow us to drop the ChangeLog files at some point. > Now there's one more step on the commit path, and a useless one at > that: the changelog entry is available in the change itself and in the > message to the mailing list. C-x v v can copy the message from ChangeLog for you (and set Author: and Fixes: at the same time), so it's not so bad. The way to fix this, is to make ChangeLog unneeded. First step on this path is to provide some way to make `C-x 4 a' usable without ChangeLog. >>> +The @code{cl-defstruct} package also provides a few structure >>> +introspection functions. >> I'm curious: when/where did you bump against a need for that? > I have a few private macros that lexically bind structure slots, Which part makes it impossible/impractical to use standard accessors for that? > and this information is also needed for some interface-generation work > I'm thinking of doing. Not sure what "interface-generation" means, but it sounds interesting. >>> +@defun cl-struct-set-slot-value struct-type slot-name inst value >> We don't need this, since we can always use setf instead. > So? We have both (setf (aref ...) ...) and (aset ...). That's only because (setf (aref ...) ...) needs to macroexpand to something. [ It's one of the differences between Common-Lisp and Elisp. ] In your case, (setf (cl-struct-slot-value ...) ...) can macroexpand to something without needing cl-struct-set-slot-value. Actually, in order for (incf (cl-struct-slot-value ...)) not to compute the offset twice, (setf (cl-struct-slot-value ...) ...) will end up expanding to something else than a call to cl-struct-set-slot-value. > That test was there in cl-check-type. The test doesn't make sense to me > either. We should drop it in both places if we drop it in cl-the. Great, let's drop it then. Thanks. >>> +(cl-define-compiler-macro cl-struct-slot-value >> Please use (declare (compiler-macro ..)). > Why? In both cases, the compiler macro is written out-of-line and in > both cases, we just stick the compiler macro on the symbol's plist. Because that's the style we use in Elisp. Note that (declare (compiler-macro ..)) can provide the compiler-macro "inline" or "out-of-line". >> I guess this goes back to the earlier question about when/where the use >> for this functionality came up. > Unless we're using this functionality in generated code where, while the > slot is constant, it's more convenient to use that slot's name than to > try to determine the accessor name. Ah, so it's for code generated based on cl-struct-slot-info? Right, that makes sense. Stefan