Re: Worrying development

[Tom Lord <lord@emf.net>]

    > 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?

    > 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