|
From: | Dirk Herrmann |
Subject: | Re: Worrying development |
Date: | Fri, 23 Jan 2004 12:45:37 +0100 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 |
Tom Lord wrote:
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.> From: Dirk Herrmann <address@hidden>> 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?
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.
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.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.
Best regards Dirk Herrmann
[Prev in Thread] | Current Thread | [Next in Thread] |