[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Worrying development

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:

   > 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))
         (set-car! l2 'x)
         (equal? l1 l3))

> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]