Re: Guile: What's wrong with this?

[Ludovic Courtès]

Hi!

Mike Gran <address@hidden> 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’.