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: Thu, 16 Mar 2017 17:32:26 -0400 Message-ID: References: <87pokampa4.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> <864lytvviq.fsf@molnjunk.nocrew.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1489699985 1494 195.159.176.226 (16 Mar 2017 21:33:05 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 16 Mar 2017 21:33:05 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 16 22:33:00 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 1cod0y-0007s2-FF for ged-emacs-devel@m.gmane.org; Thu, 16 Mar 2017 22:32:57 +0100 Original-Received: from localhost ([::1]:45882 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cod14-00028p-CP for ged-emacs-devel@m.gmane.org; Thu, 16 Mar 2017 17:33:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44024) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cod0r-00027A-Jf for emacs-devel@gnu.org; Thu, 16 Mar 2017 17:32:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cod0o-0007Yz-EV for emacs-devel@gnu.org; Thu, 16 Mar 2017 17:32:49 -0400 Original-Received: from [195.159.176.226] (port=47872 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cod0o-0007WE-81 for emacs-devel@gnu.org; Thu, 16 Mar 2017 17:32:46 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1cod0b-0005jJ-3O for emacs-devel@gnu.org; Thu, 16 Mar 2017 22:32:33 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 36 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:srG0qI41PbP2rVmDmOvfSeM5Dzk= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 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:213079 Archived-At: > A full bootstrap build still fails for me: > cedet/ede.el:46:1:Error: Wrong type argument: sequencep, > #%[cl-slot-descriptor expanded nil boolean ((:documentation . "State of an > object being expanded in speedbar."))] Looks like I missed a place where a copy-sequence needs to be turned into a copy-record? I know there's still this bug in cl-defstruct's definition of the copy- function, but I think this is never used, so it's probably somewhere else. >> We're going to have trouble preserving backward compatibility with >> pre-existing .elc files. 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'. > What if we relax the type check to use (aref object 0) instead? But we need an arrayp or recordp check before, so it'd be something like (and (or (arrayp x) (recordp x)) (aref x 0)) Problem is that now we're slower than we were before the introduction of `record`. One option could be to change `type-of' so as to know about the old struct format, and to make this backward compatibility hack dependent on a boolean var which defaults to nil but would be set to t as soon as we detect the use of an old-style struct. > That works for both old and new instances, as long as :initial-offset > is 0. :initial-offset is always 0 if :type is not `vector` or `list`, so we don't have to worry about this issue. Stefan