From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Greg Troxel Newsgroups: gmane.lisp.guile.user Subject: Re: shared-substrings missing in 1.7 Date: 16 Jan 2004 14:13:00 -0500 Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Message-ID: References: <1074242951.6739.5.camel@localhost> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1074281796 11429 80.91.224.253 (16 Jan 2004 19:36:36 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 16 Jan 2004 19:36:36 +0000 (UTC) Cc: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Fri Jan 16 20:36:13 2004 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AhZlM-0003t7-00 for ; Fri, 16 Jan 2004 20:36:12 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AhZjS-0007eB-Rn for guile-user@m.gmane.org; Fri, 16 Jan 2004 14:34:14 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AhZYV-0005Bo-1c for guile-user@gnu.org; Fri, 16 Jan 2004 14:22:55 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AhZSJ-0003xV-Ll for guile-user@gnu.org; Fri, 16 Jan 2004 14:17:03 -0500 Original-Received: from [192.1.100.210] (helo=fnord.ir.bbn.com) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AhZOv-0002r5-4T for guile-user@gnu.org; Fri, 16 Jan 2004 14:13:01 -0500 Original-Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id 8C0F02262; Fri, 16 Jan 2004 14:13:00 -0500 (EST) Original-To: Roland Orre In-Reply-To: <1074242951.6739.5.camel@localhost> Original-Lines: 78 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.2 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 Xref: main.gmane.org gmane.lisp.guile.user:2617 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:2617 This is a guile-specific non-R5RS feature, AFAICT. It seems a bit non-Schemely, too, for a mutation of one object to cause another to change (exercise for the reader: write denotational semantics for this :-). But I see the point of not withdrawing stuff that people depend on. And I note that make-shared-substring is not flagged as deprecated in 1.6.3, even though Marius says it is: http://mail.gnu.org/archive/html/guile-devel/2003-10/msg00027.html gdt 775 ~ > GUILE_WARN_DEPRECATED=detailed guile guile> (version) "1.6.3" guile> (activate-readline) guile> (define a "foobar") guile> (define b (make-shared-substring a 0 3)) guile> (string-upcase! b) "FOO" guile> b "FOO" guile> a "FOObar" guile> (exit) gdt 776 ~ > (I know GUILE_WARN_DEPRECATED=detailed works since I just hit some deprecated stuff elsewhere with this same guile binary, such as export vs re-export and c calls to define functions.) But, guile.info indeed says it is deprecated: Guile Scheme provides the concept of the "shared substring" to improve performance of many substring-related operations. A shared substring is an object that mostly behaves just like an ordinary substring, except that it actually shares storage space with its parent string. - Deprecated Scheme Procedure: make-shared-substring str [start [end]] But, shared substrings are supposed to be immutable (even though they are not): Because creating a shared substring does not require allocating new storage from the heap, it is a very fast operation. However, because it shares memory with its parent string, a change to the contents of the parent string will implicitly change the contents of its shared substrings. (string-set! foo 7 #\r) bar => "quirk" Guile considers shared substrings to be immutable. This is because programmers might not always be aware that a given string is really a shared substring, and might innocently try to mutate it without realizing that the change would affect its parent string. (We are currently considering a "copy-on-write" strategy that would permit modifying shared substrings without affecting the parent string.) In general, shared substrings are useful in circumstances where it is important to divide a string into smaller portions, but you do not expect to change the contents of any of the strings involved. So even though I really don't like backwards-incompat changes, it seems that removing them is reasonable, and that you are having trouble because you are relying on undefined behavior: As I've used shared substrings it is also non trivial to change the code. So it sounds like you have code that depends on the cross-mutability behavior. It seems that would also break if the COW semantics were implemented as threatened (with hidden shared substrings). Does your code break if you (define make-shared-substring substring)? -- Greg Troxel _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user