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,gmane.lisp.guile.devel Subject: Re: Worrying development Date: Fri, 23 Jan 2004 15:25:21 -0800 (PST) Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Message-ID: <200401232325.PAA28016@morrowfield.regexps.com> References: <1074246064.6729.23.camel@localhost> <87vfn9ufvw.fsf@zagadka.ping.de> <400FF648.3080706@dirk-herrmanns-seiten.de> <200401221842.KAA20956@morrowfield.regexps.com> <40110961.1040808@dirk-herrmanns-seiten.de> <200401231716.JAA26107@morrowfield.regexps.com> <4011A215.8060401@dirk-herrmanns-seiten.de> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1074899713 11977 80.91.224.253 (23 Jan 2004 23:15:13 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 23 Jan 2004 23:15:13 +0000 (UTC) Cc: guile-user@gnu.org, guile-devel@gnu.org, mvo@zagadka.de Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sat Jan 24 00:15:04 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 1AkAW0-0003UD-00 for ; Sat, 24 Jan 2004 00:15:04 +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 1AkAUJ-0003RZ-DZ for guile-user@m.gmane.org; Fri, 23 Jan 2004 18:13:19 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AkATo-0003N2-J2 for guile-user@gnu.org; Fri, 23 Jan 2004 18:12:48 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AkATI-0002uM-Pr for guile-user@gnu.org; Fri, 23 Jan 2004 18:12:47 -0500 Original-Received: from [199.232.41.8] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1AkATI-0007Nx-Gf; Fri, 23 Jan 2004 18:12:16 -0500 Original-Received: from [65.234.195.150] (helo=morrowfield.regexps.com) by mx20.gnu.org with esmtp (Exim 4.24) id 1AkAT8-0003eH-Br; Fri, 23 Jan 2004 18:12:06 -0500 Original-Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id PAA28016; Fri, 23 Jan 2004 15:25:21 -0800 (PST) (envelope-from lord@morrowfield.regexps.com) Original-To: dirk@dirk-herrmanns-seiten.de In-reply-to: <4011A215.8060401@dirk-herrmanns-seiten.de> (message from Dirk Herrmann on Fri, 23 Jan 2004 23:37:09 +0100) 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:2703 gmane.lisp.guile.devel:3298 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3298 > From: Dirk Herrmann > As you say, the standard only describes functions that, on creation of > strings, requires to allocate fresh locations for the contents of the > strings. That is, someone who only uses the functions that are described > by the standard is not able to create any mutation-sharing substring. > And this, implicitly, indicates that different (in the sense of eq?) > strings use different locations for their contents. To me this seems > like a valid assumption. It's subtly wrong. A program (or, more importantly, a module) can assume that non-eq? strings are disjoint in their storage _if_and_only_if_ either (1) it knows how both strings were created or (2) it's assumption-of-disjointness is shared with the caller who passes the strings to the module. (1) is trivially obvious. (2) may sound onerous but it really isn't. It falls out of the existing practice of procedures advertising clearly what arguments they mutate. A caller passing around mutation-sharing strings has to be careful to pass them to mutating procedures only when they are certain that they want mutations to be shared. Ultimately, that obligation propogates right back to the point of creation of the mutation-sharing substring --- using mutation-sharing substrings is, every step of the way, a perfectly localized (a perfectly "modular") decision. You keep worrying about what happens if a procedure mutates a string and then is "surprised" when that mutation effects some other string. No procedure need worry about that -- it is entirely up to code which _creates_ a mutation-sharing string to only pass it to a mutating procedure when it knows what it's doing. > Standard-conforming scheme programs may IMO > rely on this fact [that non-eq? strings can't possibly share > mutations] Freestanding portable standard programs can rely on that fact -- and adding mutation-sharing substrings doesn't change that in the slightest. Modules, intended to be combined with other modules that may be using non-standard feature can _not_ rely on that fact and have never been able to rely on that fact. Mutation-sharing substrings drive that point home but they aren't the only reason. But that property of modules is not really a problem in practice. You have to have a pretty twisted Scheme programming style to run into a case where it will make a difference. > >Mutation-sharing shared substrings are an upwards compatible extension > >to the Scheme standard. They break no correct programs. They enable > >new kinds of programs. > Introducing a separate data type for mutation-sharing character arrays > also enables new kinds of programs. The difference between a separate > data type and the former implementation is, that mutation-sharing > substrings could be used everywhere where an ordinary string had been > used before. That is, the difference is a matter of being able to re-use > existing string-handling code rather than enabling new kinds of > programs. However, it is exactly this re-using of existing > string-handling code issue which becomes problematic when the semantics > of the string objects change. I don't believe that it's problematic in the slightest. Certainly no more so than re-using a standard Scheme module in a multi-threaded Scheme. > Marius, would it be an acceptable compromise to require that the > mutation-sharing substring issue be submitted and discussed as an srfi > before it becomes an official part of guile's core? The discussion of > the topic in that forum would reduce the risk that the change introduces > problems. I would then ask those who are interested to have it as a part > of guile to submit a srfi proposal. > (Please note that, as I have said before, I have nothing against > providing mutation-sharing substrings as a deprecated feature for some > period - but not as an official part of guile's core.) I guess what really bugs me about the issue is that the feature was (semi-) removed based on pure speculation, opinion, and apparently by imperfect interpretation of the standard. I don't think that there was a record of the feature causing any serious and sustained problems. It's removal seemed rather a rather gratuitous snub. -t _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user