Re: The empty string and other empty strings

[Mark H Weaver]

David Kastrup <address@hidden> writes:

> Mark H Weaver <address@hidden> writes:
>
>> I went ahead and committed this optimization.  Empty substrings are now
>> always freshly allocated, and never hold a reference to the original
>> stringbuf.
>
> Why would they need an allocation at all?  They don't contain
> characters.

It is an arguable point, but although they don't contain characters,
they can still be compared with other objects using `eq?'.

The R5RS says that `string', `make-string', `substring',
`string-append', `list->string', and `string-copy' return a newly
allocated string, which implies that the returned string is not `eq?' to
any other existing object.

Admittedly, the R5RS also says that `list' returns a newly allocated
list, which obviously cannot be true for the empty list.

Nonetheless, it still seems safer to strictly follow the standard here.
I expect that most implementations produce newly allocated empty strings
(since that's what naturally happens unless you handle empty strings
specially) and some programs might depend on this behavior, especially
since the standard seems to mandate it.

On the other hand, I don't expect that enough empty strings are created
to make the optimization very significant, though perhaps I'm mistaken.
Empty string literals ("") will still be shared, for what it's worth.

What do other people think?

    Mark