From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Tom Lord Newsgroups: gmane.lisp.guile.user Subject: Re: shared-substrings missing in 1.7 Date: Fri, 16 Jan 2004 12:45:42 -0800 (PST) Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Message-ID: <200401162045.MAA05882@morrowfield.regexps.com> References: <1074242951.6739.5.camel@localhost> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1074285568 20157 80.91.224.253 (16 Jan 2004 20:39:28 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 16 Jan 2004 20:39:28 +0000 (UTC) Cc: guile-user@gnu.org, orre@nada.kth.se Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Fri Jan 16 21:39:21 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 1AhakS-0008Vf-00 for ; Fri, 16 Jan 2004 21:39:21 +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 1AhahR-0006bI-Nz for guile-user@m.gmane.org; Fri, 16 Jan 2004 15:36:13 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1Ahag5-0006Pk-Ro for guile-user@gnu.org; Fri, 16 Jan 2004 15:34:49 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AhafW-0006En-Sc for guile-user@gnu.org; Fri, 16 Jan 2004 15:34:45 -0500 Original-Received: from [65.234.195.89] (helo=morrowfield.regexps.com) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AhafV-0006ED-EX for guile-user@gnu.org; Fri, 16 Jan 2004 15:34:13 -0500 Original-Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id MAA05882; Fri, 16 Jan 2004 12:45:42 -0800 (PST) (envelope-from lord@morrowfield.regexps.com) Original-To: gdt@ir.bbn.com In-reply-to: (message from Greg Troxel on 16 Jan 2004 14:13:00 -0500) 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:2620 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:2620 > From: Greg Troxel > 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 > :-). Why is that significantly different from a mutation of one list changing another? (define x (list 'b 'c 'd)) (define y (cons 'a x)) y => (a b c d) (set-car! x 'semantics-schmemantics) y => (a semantics-schmemantics c d) Specifying the semantics of mutation-effects-both shared substrings is as easy as specifying the semantics of cons pairs. > But, shared substrings are supposed to be immutable Ideally there would be two kinds of shared substring: copy-on-write and mutation-effects-both. MAKE-SHARED-SUBSTRING would create a mutation-effects-both shared substring; SUBSTRING could create a copy-on-write shared substring. MAKE-COW-SUBSTRING could have the same meaning as SUBSTRING but provide a distinct hint to the implementation about how the string is expected to be used. > 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.) That's all fine but when a programmer knows what she is doing, a mutation-effects-both string is potentially exactly what is wanted. How about something like: (string-downcase! (make-shared-substring from:-line hostname-start hostname-end)) to turn: "Greg Troxel" into "Greg Troxel" The equivalent-performance alternative there is to make STRING-DOWNCASE! and all similar functions accept optional START/END parameters -- a solution that quickly gets quite out of hand. > 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. Not "In general" but "In some cases". > 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: It didn't start out as undefined. When first added, MAKE-SHARED-SUBSTRING returned a mutation-effects-both substring. It was a feature. -t _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user