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: Thu, 22 Jan 2004 10:42:52 -0800 (PST) Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Message-ID: <200401221842.KAA20956@morrowfield.regexps.com> References: <1074246064.6729.23.camel@localhost> <87vfn9ufvw.fsf@zagadka.ping.de> <400FF648.3080706@dirk-herrmanns-seiten.de> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1074796536 7045 80.91.224.253 (22 Jan 2004 18:35:36 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 22 Jan 2004 18:35:36 +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 Thu Jan 22 19:35:28 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 1Ajjfs-0000sa-00 for ; Thu, 22 Jan 2004 19:35:28 +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 1AjjeP-0001Mj-U0 for guile-user@m.gmane.org; Thu, 22 Jan 2004 13:33:57 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AjjdD-0001Jm-E5 for guile-user@gnu.org; Thu, 22 Jan 2004 13:32:43 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1Ajjcg-00015R-Ao for guile-user@gnu.org; Thu, 22 Jan 2004 13:32:41 -0500 Original-Received: from [65.234.195.150] (helo=morrowfield.regexps.com) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AjjaK-0000M4-Dk; Thu, 22 Jan 2004 13:29:44 -0500 Original-Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id KAA20956; Thu, 22 Jan 2004 10:42:52 -0800 (PST) (envelope-from lord@morrowfield.regexps.com) Original-To: dirk@dirk-herrmanns-seiten.de In-reply-to: <400FF648.3080706@dirk-herrmanns-seiten.de> (message from Dirk Herrmann on Thu, 22 Jan 2004 17:11:52 +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:2690 gmane.lisp.guile.devel:3284 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3284 > From: Dirk Herrmann > What may users of a string data type expect? Shall it be granted > that the following expression will always evaluate to true? > (if (and > (not (eq? s1 s2)) > (equal? s1 s3)) > (begin > (string-set! s2 0 #\x) > (equal? s1 s3)) > #t) What about: (if (and (not (eq? l1 l2)) (equal? l1 l3)) (begin (set-car! l2 'x) (equal? l1 l3)) #t) > My assumption is that most users will assume the above expression to > evaluate to true. When do they need to make such assumptions? Why is it different from the case with lists? > If that was not the case, we would require users to > perform aliasing checks in their code. Do we really want that? I've never seen list-mutating code make such checks. Why would strings be different? > The shared substring feature was deprecated since we had > considered that feature as a bug in guile's design. I propose > not to officially re-introduce it in its former way. The best > thing was to have code changed that used the old behaviour. To > allow applications to be migrated incrementally, we have > provided the feature as deprecated since guile-1.6. If that is > not possible for some applications, then a workaround like the > one that Mikael and Roland have developed can be used. With that > solution, the feature may even remain part of guile - but > deprecated, only provided for backwards compatibility! Whoever > uses it, should be aware of the fact that due to the aliasing it > may lead to problems with other string libraries. I am having trouble imagining any libraries that would break. Let's suppose that, eventually, Guile has _both_ COW shared substrings and shared-mutation shared substrings. The only reason I would ever create a shared-mutation shared substring in the first place is if I know that I want to mutate it (or it's parent or some other shared-mutation string) and have the effect on all of these strings. Now what if I have shared-mutation substrings but not COW? You say that the old implementation was flawed because it created _only_ shared mutation substrings. I don't think that that's a very serious flaw. In general, no procedure should mutate _any_ of its arguments unless it is advertised as doing so. Consequently, I simply shouldn't hand a shared-mutation substring to a mutating procedure unless I intend for that mutation to effect all sharing strings. And on the other hand, if I have a mutating procedure -- almost invariably the mutation is _unconditional_. The "copy" of a COW substring is guaranteed to take place. If I'm going to pass a substring to a mutating procedure and _don't_ want the mutations to propogate, then I may as well do the "copy" eagerly in the first place. That decision to share mutations or not is one I can make locally -- at the point where I create the substring in the first place. Libraries don't have to worry that I might have made that decision for some parameters at all. It's not their business. There's no need for aliasing checks. Even if a library _wanted_ to worry about aliasing it couldn't: it doesn't know what other strings to check for aliasing. So, no, sorry -- the old implementation (shared-mutation-only) was very good. Adding a COW behavior to SUBSTRING is an upwards-compatible improvement to the old way -- since many uses of SUBSTRING in portable Scheme programs will never need to perform the copy -- but if you have only one of the two kinds of shared substring, shared-mutation gives you the greater functionality at essentially no cost to correct standard programs. As I vaguely recall, the only reason COW didn't become the behavior of SUBSTRING "back then" was because of a tag-bit shortage (at the time). It was something I had planned to eventually squeeze in. -t _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user