On Sat, Jul 30, 2022, 8:50 AM Lynn Winebarger wrote: > On Sat, Jul 30, 2022, 8:25 AM Po Lu wrote: > >> Lynn Winebarger writes: >> > 4) Make a special read syntax for literal docstrings, e.g. #", and do >> away with the weird context-sensitive semantics of ordinary string literals >> altogether. >> > >> > Also, the test in read_literal_string should probably be for >> "will_dump_p" rather than the purify flag, since it's the dumping that >> prompts the deferral of docstring >> > loading, not the identification of constants. >> > >> > Any preferences? >> >> None in particular, except that option 4 is unacceptable as it is not >> compatible with older code, and is completely different from all other >> Lisp implementations. >> > > Not compatible in what sense? > I'm not that familiar with lisp implementations - isn't Emacs's treatment > of a leading escaped literal newline already completely different? Is > there a typical use of #" as a reader macro? It's"undefined" according to > https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node191.html > Also, I'm only talking about the treatment of docstrings by the reader. The byte compiler has much more accurate identification of docstrings that can be relied on when using the bootstrap emacs to byte compile files to be pre-loaded. Another approach would to eliminate the special treatment by the reader altogether to the extent it only saves space in the bootstrap dump, then rely on lazy loading from byte-compiled files for docstrings in lisp files. That might require evicting those docstrings during the first post-bootstrap dump, or just eliminating them from the function symbol property during the bootstrap dump, since who is using the help system in the bootstrap emacs? Lynn