On Sep 19, 2009, at 1:37 PM, John Cowan wrote:

>> I shouldn't have to use `string-copy' for this; my implementation  
>> should
>> do it for me. If there's no user-exposed backpointer from the  
>> substring to
>> the original string, the GC can dispose of the original string and  
>> copy
>> out the retaining displaced substrings when it makes sense to do so.
>
> Nevertheless, few extant GCs do so, notably not the Boehm  
> conservative GC.
> So string-copy is a kludge, but a useful kludge.

I believe that this is expressible in terms of weak pointers and  
finalizers (both of which are supported by the Boehm collector). Each  
non-displaced string object holds a weak pointer to any displaced  
substrings, and the actual string storage object is separately  
allocated and pointed to by all displaced substrings. When the  
original string object is reaped, its finalizer has the opportunity to  
decide whether to keep the original string storage object around in  
its entirety, to trim or split the original string storage object, or  
to copy out the displaced substrings and turn them into non-displaced  
strings. Any time a displaced substring object is reaped, this process  
can be re-run.

>> There's really no sense to providing a copy operation for an  
>> immutable
>> type.
>
> That's rather strong.  The proposed strings are immutable but not  
> interned;
> two strings that are equal? may still not be eqv?.

I'm not proposing that immutable strings be interned, but I don't  
think any promises of identity should be made. In particular, `make- 
string' and other string-building objects should be free to return the  
same (eqv?) object given the same inputs. Some string representations  
may not even have an identity: on 64-bit systems, it may be natural to  
provide an immediate representation for strings of one or two code  
points (or more, if a variable-width encoding is used).
--
Brian Mastenbrook
[email protected]
http://brian.mastenbrook.net/

_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss

Reply via email to