From: Tom Lord <lord@emf.net>
Cc: guile-user@gnu.org, guile-devel@gnu.org, mvo@zagadka.de
Subject: Re: Worrying development
Date: Thu, 22 Jan 2004 10:42:52 -0800 (PST) [thread overview]
Message-ID: <200401221842.KAA20956@morrowfield.regexps.com> (raw)
In-Reply-To: <400FF648.3080706@dirk-herrmanns-seiten.de> (message from Dirk Herrmann on Thu, 22 Jan 2004 17:11:52 +0100)
> 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
next prev parent reply other threads:[~2004-01-22 18:42 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-16 9:41 Worrying development Roland Orre
2004-01-16 11:59 ` tomas
2004-01-18 21:05 ` Marius Vollmer
2004-01-18 21:58 ` Tom Lord
2004-01-22 21:47 ` Tom Lord
2004-01-22 16:11 ` Dirk Herrmann
2004-01-22 18:42 ` Tom Lord [this message]
2004-01-23 11:45 ` Dirk Herrmann
2004-01-23 17:16 ` Tom Lord
2004-01-23 21:01 ` Marius Vollmer
2004-01-23 22:18 ` Tom Lord
2004-01-24 0:27 ` Marius Vollmer
2004-01-24 0:53 ` Tom Lord
2004-01-23 22:28 ` Paul Jarc
2004-01-24 12:09 ` rm
2004-01-24 13:29 ` Marius Vollmer
2004-01-26 2:42 ` overriding car/cdr (was: Worrying development) Paul Jarc
2004-02-08 16:21 ` overriding car/cdr Dirk Herrmann
2004-02-08 18:09 ` Marius Vollmer
2004-02-08 20:56 ` Paul Jarc
2004-03-20 22:28 ` Marius Vollmer
2004-03-22 17:05 ` David Van Horn
2004-03-22 21:03 ` Marius Vollmer
2004-03-22 17:24 ` Paul Jarc
2004-01-23 22:37 ` Worrying development Dirk Herrmann
2004-01-23 23:25 ` Tom Lord
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200401221842.KAA20956@morrowfield.regexps.com \
--to=lord@emf.net \
--cc=guile-devel@gnu.org \
--cc=guile-user@gnu.org \
--cc=mvo@zagadka.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).