Bruce Korb <bk...@gnu.org> writes: > On 01/04/12 15:59, Mark H Weaver wrote: >> Implementing copy-on-write transparently without the user explicitly >> making a copy (that is postponed) is _impossible_. The problem is that >> although we could make a new copy of the string, we have no way to know >> which pointers to the old object should be changed to point to the new >> one. We cannot read the user's mind. > > So because it might be the case that one reference might want to > see changes made via another reference then the whole concept is > trashed?
Yes. Because different references can't be distinguished, it would mean that you'd not actually have a reference to the modified copy after modifying it. Which renders the modification useless. > "all or nothing"? Anyway, such a concept should be kept very simple: > functions that modify their argument make copies of any input argument > that is read only. Any other SCM's lying about that refer to the > unmodified object continue referring to that same unmodified object. > No mind reading required. > (define a "hello") > (define b a) > (string-upcase! a) > b > > yields "hello", not "HELLO". Simple, comprehensible and, of course, > not the problem I was having. :) It is neither simple, nor comprehensible. > "it goes without saying (but I'll say it anyway)": > > (define a (string-copy "hello")) > (define b a) > (string-upcase! a) > b > > *does* yield "HELLO" and not "hello". Why the inconsistency? > > Because it is better to do what is almost certainly expected > rather than throw errors. > > It is an ease of use over language purity thing. You probably don't realize how ironic that is. -- David Kastrup