Another one: I've written a reader macro to allow for Perl-like string
interpolation (to be released soon) - something like
* (let ((a 42))
#?"foo: \xC4\N{U with diaeresis}\nbar: ${a}")
"foo: ??
bar: 42"
It all works fine but I have one problem: If the string includes
variable interpolations the reader macro will expand into code (as
opposed to just a converted string) and naturally it'll cons a
bit. Now, if a lot (3,000+) of these #?"" strings are contained in one
form and I load the file with this form CMUCL takes eons to load it -
it might even give up due to heap exhaustion. This doesn't happen if
the same 3,000+ strings are contained in 3,000+ different top-level
forms, though.
This seems to be like a GC-related problem to me. I can circumvent the
problem if the reader macro evaluates (ext:gc :full t) each time it is
invoked but of course this'll make it crawl. My layman guess is that
parsing such a big form takes so long that the garbage that I am
creating is promoted to a higher generation before the reader is
through with the form and thus it'll never be reclaimed unless I do it
explicitely. Could that be right? What can I do about it?
FWIW, LispWorks has the same problem while AllegroCL and CLISP read
the file without complaint.
Thanks,
Edi.
