Re: Worrying development

[Dirk Herrmann <dirk@dirk-herrmanns-seiten.de>]

Tom Lord wrote:

>    > From: Dirk Herrmann <dirk@dirk-herrmanns-seiten.de>
>
>    > 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