From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: nalaginrut Newsgroups: gmane.lisp.guile.devel Subject: Re: Guile: What's wrong with this? Date: Wed, 04 Jan 2012 17:35:16 +0800 Organization: HFG Message-ID: <1325669716.3100.16.camel@Renee-desktop> References: <4F027F35.5020001@gmail.com> <1325603029.22166.YahooMailNeo@web37906.mail.mud.yahoo.com> <4F032C41.3070300@gmail.com> <87mxa4ifux.fsf@gnu.org> <1325646278.7597.YahooMailNeo@web37902.mail.mud.yahoo.com> Reply-To: NalaGinrut@gmail.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1325669740 32545 80.91.229.12 (4 Jan 2012 09:35:40 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 4 Jan 2012 09:35:40 +0000 (UTC) Cc: Ludovic =?ISO-8859-1?Q?Court=E8s?= , "guile-devel@gnu.org" To: Mike Gran Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Jan 04 10:35:35 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 1RiNFu-00009A-PQ for guile-devel@m.gmane.org; Wed, 04 Jan 2012 10:35:34 +0100 Original-Received: from localhost ([::1]:37272 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiNFu-0001oT-Ar for guile-devel@m.gmane.org; Wed, 04 Jan 2012 04:35:34 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:52254) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiNFr-0001oG-D2 for guile-devel@gnu.org; Wed, 04 Jan 2012 04:35:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RiNFq-00082K-FF for guile-devel@gnu.org; Wed, 04 Jan 2012 04:35:31 -0500 Original-Received: from mail-iy0-f169.google.com ([209.85.210.169]:50219) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiNFo-000821-Vt; Wed, 04 Jan 2012 04:35:29 -0500 Original-Received: by iacb35 with SMTP id b35so35612197iac.0 for ; Wed, 04 Jan 2012 01:35:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:from:reply-to:to:cc:in-reply-to:references:content-type :organization:date:message-id:mime-version:x-mailer :content-transfer-encoding; bh=/yBM3qVcFbro0Ls57EgGJk0MjoH5UPgtwAiikIz+ys4=; b=DNYfNiswDMPdEuFhX2ncLOEecVTG2Lrt+8G2S2B9mG7tzOhOT4QpTEukOwb3TjKwdX h+TcrCXLlYQ2M/pvI6FjTLP4uWpxSLLsQGLoUNtSsKmpvGAjByaYKUPPhYbrCwUDlY9S xlE3xAgGTKMVnh9r1R/SE/Uksebc3dGPgrwu8= Original-Received: by 10.50.47.229 with SMTP id g5mr36836603ign.23.1325669727781; Wed, 04 Jan 2012 01:35:27 -0800 (PST) Original-Received: from [192.168.100.100] ([183.37.243.162]) by mx.google.com with ESMTPS id 5sm10007146ibe.8.2012.01.04.01.35.21 (version=SSLv3 cipher=OTHER); Wed, 04 Jan 2012 01:35:26 -0800 (PST) In-Reply-To: <1325646278.7597.YahooMailNeo@web37902.mail.mud.yahoo.com> X-Mailer: Evolution 2.28.3 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:13258 Archived-At: > > In many systems it is desirable for constants (i.e. the values of literal > > expressions) to reside in read-only-memory. To express this, it is > > convenient to imagine that every object that denotes locations is > > associated with a flag telling whether that object is mutable or immutable. > > In such systems literal constants and the strings returned by > > `symbol->string' are immutable objects, while all objects created by > > the other procedures listed in this report are mutable. It is an error > > to attempt to store a new value into a location that is denoted by an > > immutable object. > > > > In Guile this has been the case since commit > > 190d4b0d93599e5b58e773dc6375054c3a6e3dbf. > > > > The reason for this is that Guile’s compiler tries hard to avoid > > duplicating constants in the output bytecode. Thus, modifying a > > constant would actually change all other occurrences of that constant in > > the code, making it a non-constant. ;-) > > This is a terrible example of the RnRS promoting some strange idea of > mathematical purity over being useful. > > The idea that the correct way to initialize a string is > (define x (string-copy "string")) is awkward. "string" is a read-only > but copying it makes it modifyiable? Copying implies mutability? > > Copying doesn't imply modifying mutability in any other data type. > > Why not change the behavior 'define' to be (define y (substring str 0)) when STR > is a read-only string? This would preserve the shared memory if the variable is never > modified but still make the string copy-on-write. > > Regards, > > Mike > Hi guys! I just pass by and see your dispute. I have been confused by the new immutable string design. But I used a macro "make-mutable-string" which hide string-copy for an abstraction. Anyway, if the efficiency would be an issue, one may choose bytevector to implement "make-mutable-string". And it's easy to substitute with sed. BTW, can't we make an efficient "mutable-string" module for an alternative? Just like old version. I mean it could be a Guile specific feature. -- GNU Powered it GPL Protected it GOD Blessed it HFG - NalaGinrut --hacker key-- v4sw7CUSMhw6ln6pr8OSFck4ma9u8MLSOFw3WDXGm7g/l8Li6e7t4TNGSb8AGORTDLMen6g6RASZOGCHPa28s1MIr4p-x hackerkey.com ---end key---