From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: Functional record "setters", a different approach Date: Fri, 13 Apr 2012 17:41:02 +0200 Message-ID: <874nsn1vxt.fsf@gnu.org> References: <87fwcaah4w.fsf@netris.org> <87r4vthpti.fsf@gnu.org> <874nsp800i.fsf@netris.org> <87vcl4203n.fsf@gnu.org> <87vcl475qs.fsf@netris.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1334331677 28826 80.91.229.3 (13 Apr 2012 15:41:17 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 13 Apr 2012 15:41:17 +0000 (UTC) Cc: guile-devel@gnu.org To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Apr 13 17:41:16 2012 Return-path: Envelope-to: guile-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 1SIice-0002fx-AA for guile-devel@m.gmane.org; Fri, 13 Apr 2012 17:41:16 +0200 Original-Received: from localhost ([::1]:43721 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SIicd-0000if-Kr for guile-devel@m.gmane.org; Fri, 13 Apr 2012 11:41:15 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:48533) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SIica-0000iZ-QC for guile-devel@gnu.org; Fri, 13 Apr 2012 11:41:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SIicU-0003xP-92 for guile-devel@gnu.org; Fri, 13 Apr 2012 11:41:12 -0400 Original-Received: from xanadu.aquilenet.fr ([88.191.123.111]:51072) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SIicT-0003xF-W7 for guile-devel@gnu.org; Fri, 13 Apr 2012 11:41:06 -0400 Original-Received: from localhost (xanadu.aquilenet.fr [127.0.0.1]) by xanadu.aquilenet.fr (Postfix) with ESMTP id 8A474FC8; Fri, 13 Apr 2012 17:41:03 +0200 (CEST) Original-Received: from xanadu.aquilenet.fr ([127.0.0.1]) by localhost (xanadu.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNoIqjk74IvX; Fri, 13 Apr 2012 17:41:03 +0200 (CEST) Original-Received: from pluto (unknown [193.50.110.130]) by xanadu.aquilenet.fr (Postfix) with ESMTPSA id 2FC3CE2B; Fri, 13 Apr 2012 17:41:03 +0200 (CEST) X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 25 Germinal an 220 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 83C4 F8E5 10A3 3B4C 5BEA D15D 77DD 95E2 EA52 ECF4 X-OS: x86_64-unknown-linux-gnu In-Reply-To: <87vcl475qs.fsf@netris.org> (Mark H. Weaver's message of "Thu, 12 Apr 2012 21:58:03 -0400") User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.93 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 88.191.123.111 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:14263 Archived-At: Hi Mark! And Happy Friday, as our friend would say. :-) Mark H Weaver skribis: > ludo@gnu.org (Ludovic Court=C3=A8s) writes: >> Mark H Weaver skribis: >>> ludo@gnu.org (Ludovic Court=C3=A8s) writes: >>>> I=E2=80=99d still want named single-field setters, for convenience. F= or that, >>>> we probably still need a separate =E2=80=98define-immutable-record-typ= e=E2=80=99. >>> >>> Agreed. >> >> Cool! Could you integrate it somehow, along with the tests I provided? > > Will do. Thanks! >>> However, I find the term 'set' misleading, since no mutation is taking >>> place. Maybe 'update'? I dunno, I don't have strong feelings on this. >> >> I don=E2=80=99t find =E2=80=98set=E2=80=99 misleading because there=E2= =80=99s no exclamation mark, and >> because it=E2=80=99s conceptually about setting a field=E2=80=99s value.= WDYT? > > Okay, on second thought I'm inclined to agree. 'set' is a good choice. [...] > What do you think? I=E2=80=99d say =E2=80=98set-fields=E2=80=99, no? (There are actually two common conventions: one is TYPE-METHOD, as in =E2=80=98vector-ref=E2=80=99, and another is VERB-NAME, as is =E2=80=98make= -list=E2=80=99, =E2=80=98let-values=E2=80=99. I tend to prefer the latter, but sometimes the former is more convenient or clearer.) [...] >> Would these checks be alleviated by Andy=E2=80=99s work on peval =E2=80= =9Cpredicates=E2=80=9D? > > Unfortunately, no. The 'vtable' field of a struct is a mutable field, > and in fact when a GOOPS class is redefined, the 'vtable' field of > instances are modified. This means that it is not safe for the compiler > to eliminate redundant calls to 'struct-vtable'. Oh, OK. That is eviiiil. >>> For example, for (modified-copy s ((foo-x) 'new)) where 's' contains 10 >>> fields, the expanded code would include 9 separate checks that 's' is >>> the right type. >> >> Couldn=E2=80=99t =E2=80=98modified-copy=E2=80=99 be implemented differen= tly so that there=E2=80=99s only >> one check? That seems like the most obvious (not necessarily the >> easiest) way to address the problem. > > Yes, and that's exactly what I did. However, I was only able to > accomplish this by essentially hacking up my own '-nocheck'. > > If I had used the normal getters in the expansion of 'modified-copy', > then (modified-copy s ((foo-x) 'new)) would expand to: > > (make-struct 0 > (foo-q s) (foo-r s) (foo-s s) (foo-t s) (foo-u s) > (foo-v s) (foo-w s) 'new (foo-y s) (foo-z s)) > > and each of those getter uses would include a type-check in their > expansions. As you suggested, I instead wrap a single check around the > whole thing and then effectively use (foo-*-nocheck s) instead, by using > 'struct-ref' directly. > > This example is intended to convince you that 'nocheck' variants of > struct accessors are important as a base upon which to build efficient > higher-level constructs, at least for our own internal use. I view it as an important =E2=80=9Cimplementation detail=E2=80=9D, but not = as an API to be exposed publicly. What about keeping it private until we find an actual use case where it is required outside of (srfi srfi-9)? Thanks! Ludo=E2=80=99.