From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] trunk r116995: cl-lib defstruct introspection Date: Mon, 21 Apr 2014 10:40:50 -0700 Message-ID: <53555822.3080007@dancol.org> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5WLM9lTcOiThJ1kmuFkp7UeQSl5Brfn85" X-Trace: ger.gmane.org 1398102067 32077 80.91.229.3 (21 Apr 2014 17:41:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Apr 2014 17:41:07 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 21 19:41:02 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 1WcIDF-0003iU-DA for ged-emacs-devel@m.gmane.org; Mon, 21 Apr 2014 19:41:01 +0200 Original-Received: from localhost ([::1]:50575 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WcIDF-00037t-0v for ged-emacs-devel@m.gmane.org; Mon, 21 Apr 2014 13:41:01 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43425) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WcID8-000343-Ud for emacs-devel@gnu.org; Mon, 21 Apr 2014 13:40:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WcID6-00088f-NA for emacs-devel@gnu.org; Mon, 21 Apr 2014 13:40:54 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:39752) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WcID6-00088Y-6w for emacs-devel@gnu.org; Mon, 21 Apr 2014 13:40:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=wU6zm6rrCaEv1Ctahw96d+2D4PA1lIvhZeBW/UAujZQ=; b=hki+QXhOKf4e7xsZjmUNuUEoiPpJkl25QwBP8T44coOv9cwy7VMwvp8hSgSDPwL60E9FRZUuBrht3CFXGq0L9/+lJo832FQ6NO8Rwx9UXr2kijBBjoptPZAh0ukN99r5s3aps7QDyprvj01AScklo5PSa0wuZ3xtfqr6cre17ERXJAGv7f8wwbOT6RWxWFcEg2Hph08X2b0+ttGfC3cM/mJh5jHEZQOoFF5A/vFhIjqsECXYwZqBgLBag6zgqQaPKAQK2McQHCQ9SHZwhRMkfMK0eL5mkEGlRjdPWKs4ANCAkSXvkyIxHlNidY0rzuzJGfHgZr1+13w9mts73Eae7w==; Original-Received: from [2601:8:b200:2b6::2b1] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WcID5-000367-7Q; Mon, 21 Apr 2014 10:40:51 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 In-Reply-To: X-Enigmail-Version: 1.6 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:171541 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5WLM9lTcOiThJ1kmuFkp7UeQSl5Brfn85 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/21/2014 08:38 AM, Stefan Monnier wrote: > [ I wrote this yesterday already, but somehow it got eaten by Murphy or= > something. ] >=20 >> cl-lib defstruct introspection >=20 > Please always use the ChangeLog entry as commit message. That's new. Using the whole ChaneLog message has been a recommendation, but never a requirement. 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. >> +The @code{cl-defstruct} package also provides a few structure >> +introspection functions. >=20 > I'm curious: when/where did you bump against a need for that? I have a few private macros that lexically bind structure slots, and this information is also needed for some interface-generation work I'm thinking of doing. >> +@defun cl-struct-set-slot-value struct-type slot-name inst value >=20 > We don't need this, since we can always use setf instead. So? We have both (setf (aref ...) ...) and (aset ...). >> -(defun cl--const-expr-val (x) >> +(defun cl--const-expr-val (x &optional environment default) >=20 > `environment' is always macroexpand-all-environment, and `default' is > never used, so you can revert this part of the change. Sure. >> +(defmacro cl-the (type form) >> + "Return FORM. If type-checking is enabled, assert that it is of TY= PE." >> (declare (indent 1) (debug (cl-type-spec form))) >> - form) >> + (if (not (or (not (cl--compiling-file)) >=20 > Unless absolutely needed, we should drop this (cl--compiling-file) test= , > because cl--compiling-file is an ugly hack. 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. >> +(defun cl-struct-sequence-type (struct-type) >> + "Return the sequence used to build STRUCT-TYPE. >> +STRUCT-TYPE is a symbol naming a struct type. Return 'vector or >> +'list, or nil if STRUCT-TYPE is not a struct type. " >> + (car (get struct-type 'cl-struct-type))) >> +(put 'cl-struct-sequence-type 'side-effect-free t) >=20 > Please add `side-effect-free' to defun-declarations-alist, so we can > move these into `declare's, which is cleaner (it associates them with > the function itself rather than with the shared symbol). Sure. >> +(defsetf cl-struct-slot-value cl-struct-set-slot-value) >=20 > Please use (declare (gv-setter ...)) or (declare (gv-expand ...)). > Also, we should define it better such that (incf (cl-struct-slot-value = =2E.)) > only computes the offset and tests the type once. I've already changed it to gv-define-simple-setter. I don't think the incf optimization you mention matters. >> +(cl-define-compiler-macro cl-struct-slot-value >=20 > 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. >> + (&whole orig struct-type slot-name inst) >> + (or (let* ((macenv macroexpand-all-environment) >> + (struct-type (cl--const-expr-val struct-type macenv)) >> + (slot-name (cl--const-expr-val slot-name macenv))) >> + (and struct-type (symbolp struct-type) >> + slot-name (symbolp slot-name) >> + (assq slot-name (cl-struct-slot-info struct-type)) >> + (let ((idx (cl-struct-slot-offset struct-type slot-name)= )) >> + (cl-ecase (cl-struct-sequence-type struct-type) >> + (vector `(aref (cl-the ,struct-type ,inst) ,idx)) >> + (list `(nth ,idx (cl-the ,struct-type ,inst))))))) >> + orig)) >=20 > How important is this optimization? I mean, if struct-type and > slot-name are constants, then presumably, the code could have used the > accessor function instead, no? > 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. --5WLM9lTcOiThJ1kmuFkp7UeQSl5Brfn85 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTVVgiAAoJEMAaIROpHW7IZWgQAJqVAaANEQk6O5KRY+qnunsN T+2nBUubLJ3hGlnYFZq9Eyoyi1V8TvvdeIzRN2ZD1PC/lkyea9298VPB/Je+Cwmn SO1OiIQ3DtOzcWMJtejx+wCTEnkyxwMZEuOyB285l1CkrWI4ho3ir+mZdki+34af H1gzxYQ5o08B/5AOQdRxFDENXHpaBRbSWcf+8QuvKqUXO5bFcpyJiAAMkXhKqFDI /Jyvz3hWopiwbu/XOrrpbG3c55ZE4DVR1jeORCalLdFbnUIzeC7jjcYb8HUlTaVO QM4kb8Ej3HPxnuWCNaxwq9ABO9GwTA1JfEkRPP8v147r0b5nCi5oILJ6WB+VSuRw 7L1fmQH1y0/kcCLtCnkSC+Wht2YGhXuP2legCitETeIUaGXJs6Luww0upx2HqZ0b 4eiQ080XNTK43jzfH1181lPSN08lb49PKSPZmQgk9atBUFHUKi/IcUN3Z7Y+tbI2 hZLBLeCvf1h8gf7OsSDpAbUw4BF+4cJ4C8w+66SnGTYlYuHS8mUDCMCN40YGkLA9 8Ra/HXRgz4orADUkpdeN4zPXaLPvXW1lmQ5gAeN7T7ehh1cQ3YJRVj/I0gdKYzgx JgKcCCoztf+Lymngv/YVQJio39pLUYyey/u5WozlSPguqMn1ZzcQsLr/GsLIOhKc VRwJaEI9oZaeBp6kKqZd =0j6+ -----END PGP SIGNATURE----- --5WLM9lTcOiThJ1kmuFkp7UeQSl5Brfn85--