Re: Guile: What's wrong with this?

[Mike Gran]

>   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