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