From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: tomas@tuxteam.de Newsgroups: gmane.lisp.guile.user Subject: Re: GOOPS functional setter Date: Sat, 14 Jan 2017 11:08:39 +0100 Message-ID: <20170114100839.GA3366@tuxteam.de> References: <871sw6g4je.fsf@dustycloud.org> <20170113205646.GB10416@tuxteam.de> <87vatie6gf.fsf@dustycloud.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; x-action=pgp-signed Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1484388569 24881 195.159.176.226 (14 Jan 2017 10:09:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 14 Jan 2017 10:09:29 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: guile-user@gnu.org To: Christopher Allan Webber Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sat Jan 14 11:09:20 2017 Return-path: Envelope-to: guile-user@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 1cSLGv-0005St-AT for guile-user@m.gmane.org; Sat, 14 Jan 2017 11:09:17 +0100 Original-Received: from localhost ([::1]:47214 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cSLGz-0005mI-MO for guile-user@m.gmane.org; Sat, 14 Jan 2017 05:09:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56271) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cSLGT-0005lL-92 for guile-user@gnu.org; Sat, 14 Jan 2017 05:08:50 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cSLGO-0005CC-9y for guile-user@gnu.org; Sat, 14 Jan 2017 05:08:49 -0500 Original-Received: from mail.tuxteam.de ([5.199.139.25]:44405 helo=tomasium.tuxteam.de) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cSLGO-0005C6-2m for guile-user@gnu.org; Sat, 14 Jan 2017 05:08:44 -0500 Original-Received: from tomas by tomasium.tuxteam.de with local (Exim 4.80) (envelope-from ) id 1cSLGJ-0001E9-SR; Sat, 14 Jan 2017 11:08:39 +0100 In-Reply-To: <87vatie6gf.fsf@dustycloud.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 5.199.139.25 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.org gmane.lisp.guile.user:13099 Archived-At: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Jan 13, 2017 at 08:11:28PM -0600, Christopher Allan Webber wrote: > tomas@tuxteam.de writes: [fset vs clone] > I think cloning isn't as clear; what we want is something that's the > same as the previous instance of the object, but with one field changed. > Clone makes it sound the same, but the goal is change without affecting > the original. It's attempting to be the same as slot-set! but > functional, hence slot-fset. Again, inspired by set-field and > set-fields from (srfi srfi-9 gnu). Yes, and after having read your post I understood where you came from. The naming wouldn't have been discovrable for me right off. Curiously, Jan (also in this thread) came up with "clone", independently. Now I'm not trying to imply that "clone" is "more right"; actually I believe that there are two "modes" at work here. Let me speculate a bit: Perhaps from the more "strictly functional" point of view, the clone operation is less important, because, whether the thing is cloned behind the scenes or things are arranged by deep compiler magic and the clone doesn't happen after all is none of our business. Not the cloning is important, but the changed fields. In this world, the mutating counterpart (set) doesn't even exists. Clone wouldn't be an appropriate name here. - From the more "naive", "imperative" point of view, it's the clone operation what keeps us awake: allocating memory and things. Here "clone" is the right word, it seems. Perhaps what irritates me most is that "fset" is named after an imperative operation (set) and lives in a functional world. Or something. > However, I'm open to another name, if someone has something better... At the end it's not that important: you made the function, you name it :) If my questions elicit some resonance in you, then they might be useful. > (Also, it would even be nicer if it were possible to make the new > instance without copying every field manually as I did here. It would > be interesting if there were a metaclass that was smarter about slot > allocation and used some functional structure so that we didn't need to > iterate through every field just to change the one slot. I'm not sure > how hard that would be to do, or if it would be of significant benefit > in the end.) That's the more important part: the *interface* makes those things possible in the first place (whether by a more efficient clone primitive, as you envision, or by a clever compiler or both). Thus a Good Thing, regardless of its name :) thanks - -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlh5+KcACgkQBcgs9XrR2kaDDACcDLOi8W1gS9TZ0oU4w1bxswAU OgUAn0HAN1krKDEhJads7v9nIrq7mXRg =7b9N -----END PGP SIGNATURE-----