Hi!
Mike Gran <spk...@yahoo.com> skribis:
>> 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.
[...]
> 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?
Sort-of:
-- library procedure: string-copy string
Returns a newly allocated copy of the given STRING.
And a “new allocated copy” is mutable.
> Copying doesn't imply modifying mutability in any other data type.
It’s not about modifying mutability of an object (this can’t be done),
but about fresh vs. constant storage.
> 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.
I think all sorts of literal strings would have to be treated the same.
FTR, all these evaluate to #t:
(apply eq? "hello" '("hello"))
(apply eq? '(1 2 3) '((1 2 3)))
(apply eq? '#(1 2 3) '(#(1 2 3)))
This is fine per R5RS (info "(r5rs) Equivalence predicates"), but
different from Guile <= 1.8.
(I use ‘apply’ here to fool peval, which otherwise evaluates the
expressions to #f at compile-time. Andy: should peval be hacked to give
the same answer?)
Thanks,
Ludo’.
