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: Guile: What's wrong with this? Date: Wed, 04 Jan 2012 18:59:39 -0500 Message-ID: <8762grf28k.fsf@netris.org> References: <4F027F35.5020001@gmail.com> <1325603029.22166.YahooMailNeo@web37906.mail.mud.yahoo.com> <4F032C41.3070300@gmail.com> <87mxa4ifux.fsf@gnu.org> <4F038BF4.1070200@gnu.org> <87obujzmmc.fsf@Kagami.home> <4F048972.5040803@gnu.org> <87lipnm8yx.fsf@Kagami.home> <4F04D01D.5050801@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1325721607 22144 80.91.229.12 (5 Jan 2012 00:00:07 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 5 Jan 2012 00:00:07 +0000 (UTC) Cc: guile-devel@gnu.org To: Bruce Korb Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Jan 05 01:00:02 2012 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RiakU-0003hY-3t for guile-devel@m.gmane.org; Thu, 05 Jan 2012 01:00:02 +0100 Original-Received: from localhost ([::1]:56244 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiakT-0008Ms-Bt for guile-devel@m.gmane.org; Wed, 04 Jan 2012 19:00:01 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:47132) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiakR-0008Ma-8s for guile-devel@gnu.org; Wed, 04 Jan 2012 19:00:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RiakQ-0000rz-7g for guile-devel@gnu.org; Wed, 04 Jan 2012 18:59:59 -0500 Original-Received: from world.peace.net ([96.39.62.75]:33073) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiakQ-0000ru-2s; Wed, 04 Jan 2012 18:59:58 -0500 Original-Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=yeeloong) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1RiakJ-0003IQ-RI; Wed, 04 Jan 2012 18:59:52 -0500 In-Reply-To: <4F04D01D.5050801@gnu.org> (Bruce Korb's message of "Wed, 04 Jan 2012 14:18:05 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:13310 Archived-At: Bruce Korb writes: > You have to go to some extra trouble to be certain that a string > value that you have assigned to an SCM is not read only. If you're going to mutate a string, you'd better be safe and make a copy before mutating it, unless you know very clearly where it came from. Otherwise, you might be mutating a string that some other data structure still references, and it might not take kindly to having its string mutated behind its back. The fact that some string (whose origin you don't know about) might be read-only is the least of your problems. At least that problem will now be flagged immediately, which is far better than the subtle and hard-to-debug damage might be caused by mutating a string that other data structures may reference. All mutable values in Scheme are pointers. In the case of strings, that means that they're like "char *", not "char []". A great deal of code freely makes copies of these pointers instead of copying the underlying string itself. That's a very old tradition, because it is rare to mutate strings in Scheme. > If Guile were to implement copy on write, then the user would not have > to care whether a string were shared read only or not. It would be > easier to use. Guile already implements copy-on-write strings, but only in the sense of postponing the copy done by `string-copy', `substring', etc. Implementing copy-on-write transparently without the user explicitly making a copy (that is postponed) is _impossible_. The problem is that although we could make a new copy of the string, we have no way to know which pointers to the old object should be changed to point to the new one. We cannot read the user's mind. Mark