> In many systems it is desirable for constants (i.e. the values of literal > expressions) to reside in read-only-memory. To express this, it is > convenient to imagine that every object that denotes locations is > associated with a flag telling whether that object is mutable or immutable. > In such systems literal constants and the strings returned by > `symbol->string' are immutable objects, while all objects created by > the other procedures listed in this report are mutable. It is an error > to attempt to store a new value into a location that is denoted by an > immutable object. > > In Guile this has been the case since commit > 190d4b0d93599e5b58e773dc6375054c3a6e3dbf. > > The reason for this is that Guile’s compiler tries hard to avoid > duplicating constants in the output bytecode. Thus, modifying a > constant would actually change all other occurrences of that constant in > the code, making it a non-constant. ;-)
This is a terrible example of the RnRS promoting some strange idea of mathematical purity over being useful. The idea that the correct way to initialize a string is (define x (string-copy "string")) is awkward. "string" is a read-only but copying it makes it modifyiable? Copying implies mutability? Copying doesn't imply modifying mutability in any other data type. Why not change the behavior 'define' to be (define y (substring str 0)) when STR is a read-only string? This would preserve the shared memory if the variable is never modified but still make the string copy-on-write. Regards, Mike
