[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Docstring hack

From: Lynn Winebarger
Subject: Re: Docstring hack
Date: Sat, 30 Jul 2022 09:04:46 -0400

On Sat, Jul 30, 2022, 8:50 AM Lynn Winebarger <owinebar@gmail.com> wrote:
On Sat, Jul 30, 2022, 8:25 AM Po Lu <luangruo@yahoo.com> wrote:
Lynn Winebarger <owinebar@gmail.com> 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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]