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 23:05:13 -0400 Message-ID: References: <87pokampa4.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> <86a88mz9tx.fsf@molnjunk.nocrew.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1489633531 7460 195.159.176.226 (16 Mar 2017 03:05:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 16 Mar 2017 03:05:31 +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 Thu Mar 16 04:05:27 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 1coLj9-00017Z-NX for ged-emacs-devel@m.gmane.org; Thu, 16 Mar 2017 04:05:23 +0100 Original-Received: from localhost ([::1]:40586 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1coLjD-0008WO-Ul for ged-emacs-devel@m.gmane.org; Wed, 15 Mar 2017 23:05:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58464) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1coLj5-0008V9-Ds for emacs-devel@gnu.org; Wed, 15 Mar 2017 23:05:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1coLj2-0005T0-8W for emacs-devel@gnu.org; Wed, 15 Mar 2017 23:05:19 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:17868) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1coLj2-0005Rx-26 for emacs-devel@gnu.org; Wed, 15 Mar 2017 23:05:16 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B+DABF/8lY/wztSC1dHAEBBAEBCgEBg1FBhD2FV4V5kGUpAZcihhwEAgKDD0QUAQIBAQEBAQEBayiFFgEEAVYVDhALNBIUGA0kigsIsX6KVAEBAQcCJos9ijkFnESUOIhKhmKISosBNiGBBCMWCCxBhnMkiXgBAQE X-IPAS-Result: A0B+DABF/8lY/wztSC1dHAEBBAEBCgEBg1FBhD2FV4V5kGUpAZcihhwEAgKDD0QUAQIBAQEBAQEBayiFFgEEAVYVDhALNBIUGA0kigsIsX6KVAEBAQcCJos9ijkFnESUOIhKhmKISosBNiGBBCMWCCxBhnMkiXgBAQE X-IronPort-AV: E=Sophos;i="5.36,170,1486443600"; d="scan'208";a="295404927" Original-Received: from 45-72-237-12.cpe.teksavvy.com (HELO ceviche.home) ([45.72.237.12]) by smtp.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Mar 2017 23:05:14 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id C0E3C661A5; Wed, 15 Mar 2017 23:05:13 -0400 (EDT) In-Reply-To: (Stefan Monnier's message of "Wed, 15 Mar 2017 15:12:05 -0400") 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:213069 Archived-At: >> However, there is still EIEIO which may well need some expert guidance >> to update. > I can take care of that. Can you put your code on a branch like > scratch/record? OK, it's not working. I found a problem with cl-defstruct objects, tho: We're going to have trouble preserving backward compatibility with pre-existing .elc files. If you look at the macro expansion of current cl-defstruct: (macroexpand '(cl-defstruct (sm-test) a b)) => (progn (defvar cl-struct-sm-test-tags) (define-inline sm-test-p (x) (declare (side-effect-free error-free)) (inline-letevals (x) (inline-quote (and (vectorp #1=,x) (>= (length #1#) 3) (memq (aref #1# 0) cl-struct-sm-test-tags) t)))) (put 'sm-test 'cl-deftype-satisfies 'sm-test-p) (define-inline sm-test-a #2=(x) "Access slot \"a\" of `(sm-test)' struct CL-X." #3=(declare (side-effect-free t)) (inline-letevals #4=(x) (inline-quote (progn (or (memq (aref #5=,x 0) cl-struct-sm-test-tags) (signal #6='wrong-type-argument (list 'sm-test . #7=(,x)))) (aref #8=,x 1))))) (define-inline sm-test-b #2# "Access slot \"b\" of `(sm-test)' struct CL-X." #3# (inline-letevals #4# (inline-quote (progn (or (memq (aref #5# 0) cl-struct-sm-test-tags) (signal #6# (list 'sm-test . #7#))) (aref #8# 2))))) (defalias 'copy-sm-test (function copy-sequence)) (cl-defsubst make-sm-test (&cl-defs (nil . #9=((cl-tag-slot) (a) (b))) &key a b) "Constructor for objects of type `sm-test'." (declare (side-effect-free t)) (vector 'cl-struct-sm-test a b)) (eval-and-compile (cl-struct-define 'sm-test nil 'cl-structure-object 'nil nil '#9# 'cl-struct-sm-test-tags 'cl-struct-sm-test 't)) 'sm-test) As you can see, the code says it inherits from `cl-structure-object' (which now is of `record` type), but its constructor `make-sm-test` creates a vector rather than a record, so (cl-typep 'cl-structure-object) will fail if it only considers `type-of'. Even if we could arrange for cl-struct-define to override the definition of make-sm-test, that wouldn't help with all the places where make-sm-test has been inlined already. [ Of course, the reverse could happen as well: a new struct type (using `record` in its constructor) could inherit from a parent that's still using `vector`. But I think we can arrange for that to happen only in cases we don't care to support. ] Stefan