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 15:12:05 -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 1489605173 10784 195.159.176.226 (15 Mar 2017 19:12:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 15 Mar 2017 19:12:53 +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 20:12:48 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 1coELk-0001Jf-AJ for ged-emacs-devel@m.gmane.org; Wed, 15 Mar 2017 20:12:44 +0100 Original-Received: from localhost ([::1]:39151 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1coELl-0004Th-F6 for ged-emacs-devel@m.gmane.org; Wed, 15 Mar 2017 15:12:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47459) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1coELE-0004Ta-6e for emacs-devel@gnu.org; Wed, 15 Mar 2017 15:12:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1coELA-0003Mn-6b for emacs-devel@gnu.org; Wed, 15 Mar 2017 15:12:12 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:52784) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1coELA-0003MZ-0i for emacs-devel@gnu.org; Wed, 15 Mar 2017 15:12:08 -0400 Original-Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id v2FJC5rb031718; Wed, 15 Mar 2017 15:12:06 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 36C9F661A5; Wed, 15 Mar 2017 15:12:05 -0400 (EDT) In-Reply-To: <86a88mz9tx.fsf@molnjunk.nocrew.org> (Lars Brinkhoff's message of "Wed, 15 Mar 2017 19:14:18 +0100") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV5973=0 X-NAI-Spam-Version: 2.3.0.9418 : core <5973> : inlines <5744> : streams <1737081> : uri <2393072> 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.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:213048 Archived-At: > Thanks. I got past that and made it through to a dumped emacs which > uses record types for defstruct by default. Cool. > 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? >> 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`. > Understood. I'll look into storing the class object in slot 0. > I imagine there will be some circular bootstrapping problem, e.g. creating > the first record object requires a class object which is a record > object. Yes, cl-preloaded.el would likely need some extra care to get the system to bootstrap, but I'm not worried about that. > Some suggestions: > - type-of looks into the class object and returns the symbol naming the > class. Yes, that would make a lot of sense, but that means we have to impose a particular shape on the contents of slot 0. IOW it means that the representation of classes is at least somewhat known/imposed by the C code. It's probably OK. > - class-of could be introduced to return a class object, like CLOS. Sure. > - The read/print syntax for records uses the symbol for the type slot. > Reading a record would then maybe only work right if the class object > has been defined first. Not sure if that's ok. Not sure either. Of course, another option is for prin1 to print the whole class object in slot 0, and when we read it in, we handle it specially by looking at the class name inside the class object and reusing the corresponding class if it already exists. The would likely hard-code even more of the notion of class-objects into the C code. Stefan