From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: Functional record "setters", a different approach Date: Sat, 10 Nov 2012 14:03:35 -0500 Message-ID: <87vcdd9t6g.fsf@tines.lan> References: <87fwcaah4w.fsf@netris.org> <87hap189i3.fsf@tines.lan> <87r4o47k00.fsf@tines.lan> <87625fdi8p.fsf@gnu.org> <87ip9f77nn.fsf@tines.lan> <87ip9d2zhy.fsf@gnu.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: ger.gmane.org 1352574239 24847 80.91.229.3 (10 Nov 2012 19:03:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 10 Nov 2012 19:03:59 +0000 (UTC) Cc: guile-devel@gnu.org To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Nov 10 20:04:09 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 1TXGLg-0005uk-RR for guile-devel@m.gmane.org; Sat, 10 Nov 2012 20:04:08 +0100 Original-Received: from localhost ([::1]:37168 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TXGLX-00031S-CU for guile-devel@m.gmane.org; Sat, 10 Nov 2012 14:03:59 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:47919) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TXGLR-000318-JR for guile-devel@gnu.org; Sat, 10 Nov 2012 14:03:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TXGLO-0006LO-Gd for guile-devel@gnu.org; Sat, 10 Nov 2012 14:03:53 -0500 Original-Received: from world.peace.net ([96.39.62.75]:33453) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TXGLO-0006LE-C8; Sat, 10 Nov 2012 14:03:50 -0500 Original-Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=tines.lan) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TXGLG-0007UB-N8; Sat, 10 Nov 2012 14:03:42 -0500 In-Reply-To: <87ip9d2zhy.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Sat, 10 Nov 2012 17:28:57 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 96.39.62.75 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:15140 Archived-At: Hi Ludovic, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Documentation attached. Comments? Thanks! Looks good to me, modulo a few comments below. > BTW, why does =E2=80=98set-field=E2=80=99 has the record as its 2nd argum= ent instead of > 1st (unlike =E2=80=98set-fields=E2=80=99)? Good question. I followed the syntax of 'set-field' from your original patch, but that argument order did not make sense for 'set-fields'. On one hand, (set-field (person-address address-city) person "Boston") matches the order of the corresponding english "set the field (person-address address-city) of person to Boston", and thus reads a bit more naturally to my ears. On the other hand, it would be good for the two syntaxes to be consistent with each other, and (set-field ) would also be more consistent with things like 'hash-set!', 'vector-set!', etc. Honestly, I could go either way. If you think it makes sense to change the order to (set-field ), I'd be glad to make that change. Obviously it's now or never :) > +@unnumberedsubsubsec Functional ``Setters'' > + > +@cindex functional setters > + > +When writing code in a functional style, it is desirable to never alter > +the contents of records. For such code, a simple way to return new > +record instances based on existing ones is highly desirable. > + > +The @code{(srfi srfi-9 gnu)} module extends SRFI-9 with facilities to > +return new record instances based on existing ones, only with one or > +more field values changed---@dfn{functional setters}. First, the > +@code{define-immutable-record-type} works like > +@code{define-record-type}, except that setters are defined as functional > +setters. "except that the fields are immutable and the setters are ..." [...] > +@deffn {Scheme Syntax} set-field (field sub-fields ...) record value > +Return a new record of @var{record}'s type whose fields are equal to > +the corresponding fields of @var{record} except for the one specified by > +@var{field}. > + > +@var{field} must be the name of the getter corresponding to the field of > +@var{record} being ``set''. Subsequent @var{sub-fields} must be record This is the first time that "getter" is used, but it has not been made clear that you mean what has been called an "accessor" elsewhere in the doc. More generally, there is a confusing mixture of the accessor/modifier and getter/setter terminology. I wonder if it would made sense to do some kind of find/replace in this section. Other than that, it looks great, thanks! Mark