From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Noah Lavine Newsgroups: gmane.lisp.guile.devel Subject: Re: Guile: What's wrong with this? Date: Thu, 5 Jan 2012 21:38:58 -0500 Message-ID: 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> <8762grf28k.fsf@netris.org> <4F05DC47.1000202@gnu.org> <878vlldb4k.fsf@netris.org> <1325811764.22562.YahooMailNeo@web37903.mail.mud.yahoo.com> <87wr95bo9y.fsf@netris.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1325817549 3416 80.91.229.12 (6 Jan 2012 02:39:09 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 6 Jan 2012 02:39:09 +0000 (UTC) Cc: Bruce Korb , guile-devel@gnu.org To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Jan 06 03:39:05 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 1Rizhv-0003RP-VQ for guile-devel@m.gmane.org; Fri, 06 Jan 2012 03:39:04 +0100 Original-Received: from localhost ([::1]:44375 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rizhv-0003jE-FD for guile-devel@m.gmane.org; Thu, 05 Jan 2012 21:39:03 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:49684) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rizht-0003iv-91 for guile-devel@gnu.org; Thu, 05 Jan 2012 21:39:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rizhr-0002h7-RY for guile-devel@gnu.org; Thu, 05 Jan 2012 21:39:01 -0500 Original-Received: from mail-iy0-f169.google.com ([209.85.210.169]:43919) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rizhr-0002fi-OH; Thu, 05 Jan 2012 21:38:59 -0500 Original-Received: by iacb35 with SMTP id b35so2196385iac.0 for ; Thu, 05 Jan 2012 18:38:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zo4oKMm5ytKvMI2gW3IptwHyZCy2aCTFquMTUquyZpY=; b=fclBeROHr4gyTULl9ewsxY6tjFoDAWT10DzeCGQ/pRjBERx3gqBMgQaj7qbO1a5btZ r5NfS5uuol7P/0PvQfav1N0KiKjaXFC7lfvb19sEIWiGsVpvA4Ymtdcm3VkMuRbHlxcE QiMmYVpUd2qDPB1kGhY+Bbl17aLql7lb3AqXA= Original-Received: by 10.42.175.134 with SMTP id ba6mr4265369icb.23.1325817538193; Thu, 05 Jan 2012 18:38:58 -0800 (PST) Original-Received: by 10.43.51.132 with HTTP; Thu, 5 Jan 2012 18:38:58 -0800 (PST) In-Reply-To: <87wr95bo9y.fsf@netris.org> X-Google-Sender-Auth: XcVuIKZU2RmvipxkbKzuJD8oFRY X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.210.169 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:13336 Archived-At: Hello all, I must admit that I do not know much about why R5RS says that literals are constant, but I think there is a misunderstanding. Bruce does not want `define' to always copy its result. I think what he wants is for literals embedded in source code to be mutable. This would, of course, imply that each literal in the source code would be a new copy, even if they were identical. Weirdly enough, that is how my intuition works too. After all, if I made a string object in Scheme without going to any trouble, I would get a mutable object. If I write down a string, I expect to get the same sort of object. Bruce is also right that this enables quick and easy programming that munges strings. And I think the argument about putting strings in constant memory is bad - constant memory is an implementation detail. If it happens that we can store literals more efficiently when they are not mutated, then perhaps we should just detect that case and switch representations. Of course there is a trade-off here between ease of implementation and ease of use. This change seems pretty unimportant to me, especially if Python does all right with immutable strings, so I do not think it's important for us to support it. I just don't buy the arguments against supporting it. Noah On Thu, Jan 5, 2012 at 8:41 PM, Mark H Weaver wrote: > Mike Gran writes: >> It is curious that action of 'copy' really means the >> action of 'create a copy with different properties'. >> >> Shouldn't (string-copy "a") create another immutable string? > > Why would you want to copy an immutable string? > >> Likewise, shouldn't (substring "abc" 1) return an immutable substring? > > As I understand it, in the Scheme standards (at least before R6RS's > immutable pairs) the rationale behind marking literal constants as > immutable is solely to avoid needlessly making copies of those literals, > while flagging accidental attempts to modify them, since that is almost > certainly a mistake. > > If that is the only rationale for marking things read-only, then there's > no reason to mark copies read-only. =A0The philosophy of Scheme (at least > before R6RS) was clearly to make almost all data structures mutable. > > Following that philosophy, in Guile, even though (substring "abc" 1) > postpones copying the string buffer, it must create a new heap object. > Once you've done that, it is feasible to implement copy-on-write. > > Now, the immutable pairs of R6RS and Racket have an entirely different > rationale, namely that they enable vastly more effective optimization in > a compiler. =A0In this case, presumably you'd want copies to retain the > immutability. > > =A0 =A0 Mark >