From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: User-defined record types Date: Wed, 15 Mar 2017 10:38:23 -0400 Message-ID: References: <87pokampa4.fsf@ericabrahamsen.net> <8760m2mmlq.fsf@ericabrahamsen.net> <87lguq5r87.fsf@ericabrahamsen.net> <878tp0i74g.fsf@users.sourceforge.net> <87efyg6y0i.fsf_-_@drachen> <87zigwz9wx.fsf@tromey.com> <86bmtbd45s.fsf@molnjunk.nocrew.org> <86bmt42nk2.fsf_-_@molnjunk.nocrew.org> <86o9x40z35.fsf@molnjunk.nocrew.org> <86k27s0w6m.fsf@molnjunk.nocrew.org> <86fuif22o6.fsf@molnjunk.nocrew.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1489588748 28769 195.159.176.226 (15 Mar 2017 14:39:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 15 Mar 2017 14:39:08 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Lars Brinkhoff Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 15 15:39:03 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1coA4t-00075v-Ha for ged-emacs-devel@m.gmane.org; Wed, 15 Mar 2017 15:39:03 +0100 Original-Received: from localhost ([::1]:37699 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1coA4z-0006Q6-La for ged-emacs-devel@m.gmane.org; Wed, 15 Mar 2017 10:39:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41245) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1coA4N-0006PX-FZ for emacs-devel@gnu.org; Wed, 15 Mar 2017 10:38:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1coA4I-0008Vu-B1 for emacs-devel@gnu.org; Wed, 15 Mar 2017 10:38:31 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:16513) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1coA4I-0008Vl-65 for emacs-devel@gnu.org; Wed, 15 Mar 2017 10:38:26 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C8DACxUMlY/9TkSC1dHAEBBAEBCgEBg1GKVIV3kGMpAZcghhwEAgKCaEQUAQIBAQEBAQEBayiFFgEEAVYWCgMFCws0EhQYDSSKCwiwPIpgAQEBBwImiz2KOQWPW4YlhkOKHpJghmKTRzYhgQQjFggsQYZzJIlnAQEB X-IPAS-Result: A0C8DACxUMlY/9TkSC1dHAEBBAEBCgEBg1GKVIV3kGMpAZcghhwEAgKCaEQUAQIBAQEBAQEBayiFFgEEAVYWCgMFCws0EhQYDSSKCwiwPIpgAQEBBwImiz2KOQWPW4YlhkOKHpJghmKTRzYhgQQjFggsQYZzJIlnAQEB X-IronPort-AV: E=Sophos;i="5.36,168,1486443600"; d="scan'208";a="295357250" Original-Received: from 45-72-228-212.cpe.teksavvy.com (HELO ceviche.home) ([45.72.228.212]) by smtp.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Mar 2017 10:38:24 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id ED3C8661A5; Wed, 15 Mar 2017 10:38:23 -0400 (EDT) In-Reply-To: <86fuif22o6.fsf@molnjunk.nocrew.org> (Lars Brinkhoff's message of "Tue, 14 Mar 2017 18:23:05 +0100") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:213034 Archived-At: >>> - If you don't pass the :type option to cl-defstruct, you get a >>> cl-struct-FOO type tag in slot 0. >> That's right. And this symbol's value is the class object. >> The same holds for EIEIO. >> These are the main candidates for use of the new `record` type. > Yes, at first I tried to make cl-deftype do this by default. But I ran > into problems in cl-preloaded.el and cl-generic.el. I can help with that. > Right, I just wanted to list all possible variations to gain some > understanding. For example, I don't know if it makes a difference if > the slot 0 type tag has the form cl-struct-FOO as is the default, or > just FOO as when you specify :type. But now I know there might be. The cl-struct-FOO symbol was used instead of just FOO in order to try and avoid false-positives (i.e. to try and avoid mistakenly recognizing some random array as being a cl-struct object). With `record` you don't need that trick any more, so records could have the FOO symbol in their slot 0. For EIEIO objects, it would slow things down a bit, because EIEIO accessors needs to consult the class object, so the time it takes to get from (aref obj 0) to the actual class object is important: if we put the actual type symbol, that means that we'd need something like (get (aref obj 0) 'cl--class) whereas the current code uses (symbol-value (aref obj 0)) The problem being that the identifier used for the type name might already be used as a variable as well as as function, so we can't use the `symbol-value` or `symbol-function` slot. As mentioned, ideally, we'd want to store the class object directly in the slot 0. The downside is that prin1 would then dump the class object as well, so when reading dumped objects we'd end up creating another copy of the class object rather than reusing an existing class object. And this will break cl-generic dispatch which compares class objects with `eq`. Stefan