interesting point. I think one could argue that the dumping/restoring of the second argument to EQL was permitted to find and return any symbol in the image that was similar-as-constant. So in fact the answer might have been T even if (string 'foo) was not compile-time folded.

Your point holds even for the character-to-string-of-length-1 but all the same I think it's on firmer ground to fold (string #\a) => "a" because "returns a string" doesn't preclude that there might be a cache of single-character strings whose codes are in the range of base-char, and that the string could come from that cache. And that any one-character string appearing as a constant in code might also come from the cache.

If nothing else, we should make (string "foo") an identity.


On Fri, Jun 13, 2014 at 1:35 PM, Stas Boukarev <stassats@gmail.com> wrote:
Douglas Katzman <dougk@google.com> writes:

> The description allows STRING not to allocate in the case of symbol or
> string input, so it seems to me that (string #\Newline) should not require
> a "#." in front of it in user code to obtain a constant string of one
> newline.
> And if through macroexpansion we end up with (string 'foo) this should be
> folded to "FOO".
>
> Sound ok?
>
> *Description:*
The issue is coalescing,
(eql (string 'foo) "FOO") will change from NIL to T. Is that allowed? Is
that expected?

--
With best regards, Stas.