From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Dirk Herrmann Newsgroups: gmane.lisp.guile.user,gmane.lisp.guile.devel Subject: Re: Worrying development Date: Fri, 23 Jan 2004 12:45:37 +0100 Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Message-ID: <40110961.1040808@dirk-herrmanns-seiten.de> References: <1074246064.6729.23.camel@localhost> <87vfn9ufvw.fsf@zagadka.ping.de> <400FF648.3080706@dirk-herrmanns-seiten.de> <200401221842.KAA20956@morrowfield.regexps.com> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1074858778 25899 80.91.224.253 (23 Jan 2004 11:52:58 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 23 Jan 2004 11:52:58 +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 Fri Jan 23 12:52:47 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 1Ajzrj-0004h4-00 for ; Fri, 23 Jan 2004 12:52:47 +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 1AjzrU-0004RF-PI for guile-user@m.gmane.org; Fri, 23 Jan 2004 06:52:32 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AjzmN-0002f7-BY for guile-user@gnu.org; Fri, 23 Jan 2004 06:47:15 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AjzlK-0002KL-Po for guile-user@gnu.org; Fri, 23 Jan 2004 06:46:43 -0500 Original-Received: from [212.227.126.184] (helo=moutng.kundenserver.de) by monty-python.gnu.org with esmtp (Exim 4.24) id 1Ajzks-0002Ae-AC; Fri, 23 Jan 2004 06:45:42 -0500 Original-Received: from [212.227.126.208] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1Ajzkp-0006tL-00; Fri, 23 Jan 2004 12:45:39 +0100 Original-Received: from [80.131.47.219] (helo=dirk-herrmanns-seiten.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1Ajzkp-0001mL-00; Fri, 23 Jan 2004 12:45:39 +0100 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: de, en Original-To: Tom Lord In-Reply-To: <200401221842.KAA20956@morrowfield.regexps.com> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:494e3e4d1bf8dc247959c49e6f1f4215 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:2694 gmane.lisp.guile.devel:3290 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3290 Tom Lord wrote: > > 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? > First: It's not a matter of whether users *need* to make certain assumptions: It's a matter of interface definition. Scheme defines the string data type and together with it, it defines the semantics of operations on it. This gives users a set of properties they *can* rely on. Certainly, not all of the properties are *needed* in every piece of code. The difference with lists is, that lists are not _one_ object, but are made of several objects. That is, there is no statement saying that two different lists are independent of each other in the same way that two strings are independent of each other. >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. > No, I said that the old implementation was flawed because it changed the semantics of the standard scheme string type. It is certainly all right if someone wants to use something like shared mutation substrings, but IMO this should be achieved with a different data type. It may be a good idea to provide a library for this kind of feature, but it should not modify scheme's standard string type. Who operates on strings should be allowed to make all assumptions about string behaviour that belong to the definition of the string data type. Best regards Dirk Herrmann _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user