[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Worrying development
From: |
Tom Lord |
Subject: |
Re: Worrying development |
Date: |
Thu, 22 Jan 2004 10:42:52 -0800 (PST) |
> 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?
> 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
- Worrying development, Roland Orre, 2004/01/16
- Re: Worrying development, Thien-Thi Nguyen, 2004/01/16
- Re: Worrying development, tomas, 2004/01/16
- Re: Worrying development, Marius Vollmer, 2004/01/18
- Re: Worrying development, Tom Lord, 2004/01/18
- Re: Worrying development, Dirk Herrmann, 2004/01/22
- Re: Worrying development, Marius Vollmer, 2004/01/23
- Re: Worrying development, Tom Lord, 2004/01/23
- Re: Worrying development, Marius Vollmer, 2004/01/23
- Re: Worrying development, Tom Lord, 2004/01/23
- Re: Worrying development, Paul Jarc, 2004/01/23
- Re: Worrying development, rm, 2004/01/24