From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Re: Docstring hack Date: Sat, 30 Jul 2022 09:04:46 -0400 Message-ID: References: <87czdmlrd7.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000f3872105e5056930" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27453"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jul 30 15:05:57 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oHmAH-0006ug-1c for ged-emacs-devel@m.gmane-mx.org; Sat, 30 Jul 2022 15:05:57 +0200 Original-Received: from localhost ([::1]:35552 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oHmAF-0006pU-Sl for ged-emacs-devel@m.gmane-mx.org; Sat, 30 Jul 2022 09:05:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34482) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oHm9N-0005yk-VD for emacs-devel@gnu.org; Sat, 30 Jul 2022 09:05:01 -0400 Original-Received: from mail-pj1-x102d.google.com ([2607:f8b0:4864:20::102d]:53045) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oHm9M-0008VJ-6a for emacs-devel@gnu.org; Sat, 30 Jul 2022 09:05:01 -0400 Original-Received: by mail-pj1-x102d.google.com with SMTP id ha11so7001592pjb.2 for ; Sat, 30 Jul 2022 06:04:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=D9Pdiy6x+KeryZn5QoKH4mVQ8xtPaKAlreQ0zyLsBOk=; b=B3bYT4oo7ZjP+0lYvByYpMLGr6UjQocPpkg0/9AsZTAbOLkDHdyMOwjTFmWhpHDumM orvukf/zC9e0HsT9pOjC/YB4bR8jdTZ5myqbgiTKvFiBUWWxweLrw/q0ZTAEmwhwV8Lf U2+VwPBF3S3v0wgx2W4nHDRqD+KRjTZgq4TOuoWpEV7qzXdOuEC24R83aDzh9X4cEVyC dTTNjpjglk/bY/JwfMHKN7+4RB2cQvZAqW5C9Rzu9Nx/4RLWW5PSxOLBq9EvpcnSgujN VW1Ky7uKjtHfHqRg7cT14UHda9/sHPpZq9ibrRi5TcOkXOlws1w5HCx4qzpC0iNforhf gYqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=D9Pdiy6x+KeryZn5QoKH4mVQ8xtPaKAlreQ0zyLsBOk=; b=fZj/ctQbWCgMRiyRUdMTSCeXR2FWK2z24n+ih8181zTjRR7KRytWiHevBiicueHUsc yFe0s2410qCAEVwf7I2oFnlXxlN27QQdNYiv132mxj9zrnj4M22GQi1P6XIJc5uvG0Pd kU5r5bOZ5KEVanN0y6Wl3WvL3xp7JObvj17s2cAWpKbOUXbZdmEEmyoNFPM4z5j7zaSw rfwn0KtobFAkvsi5W5dVdGEHB2ecET9ikbqLSb4U6LL3uGXHOGlkD3Cf7o1esqM0cHrS EAA8ONdAd2Fbn+vInU63t3Jf5veFUOpzdE+yRPI4c+l3KAFV8RpCoIpjAEDuEd2ReUbF 3X7A== X-Gm-Message-State: ACgBeo2CCHcbXWLzTXwXV0+T63i9S6/2YMKKlOjIUQJ/W7Lizzb/hAnV 3dTFk4Kh34w3fx6D/DDnrkQnDdZslfYG0rtyD7I= X-Google-Smtp-Source: AA6agR5zPir8uSri38unv9xNNczW9538UmRtP3fyHrwdFyi8wFby0uEQIyXHZYQ7ZTyMNUUZaGiO+m7oiVgYWkJQGBM= X-Received: by 2002:a17:90b:3c4a:b0:1f2:205d:dbac with SMTP id pm10-20020a17090b3c4a00b001f2205ddbacmr9224477pjb.110.1659186298716; Sat, 30 Jul 2022 06:04:58 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::102d; envelope-from=owinebar@gmail.com; helo=mail-pj1-x102d.google.com X-Spam_score_int: -8 X-Spam_score: -0.9 X-Spam_bar: / X-Spam_report: (-0.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URI_DOTEDU=1.246 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:292872 Archived-At: --000000000000f3872105e5056930 Content-Type: text/plain; charset="UTF-8" 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 --000000000000f3872105e5056930 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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@gma= il.com> writes:
> 4) Make a special read syntax for literal docstrings, e.g. #", an= d do away with the weird context-sensitive semantics of ordinary string lit= erals altogether.
>
> Also, the test in read_literal_string should probably be for "wil= l_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?=C2=A0
I'm not that familiar with lisp implementations - isn't Emacs&= #39;s treatment of a leading escaped literal newline already completely dif= ferent?=C2=A0 Is there a typical use of #" as a reader macro?=C2=A0 It= 's"undefined" according to=C2=A0https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node191.html
<= /div>


<= /div>
Also, I'm only talking about the treatment of do= cstrings by the reader.=C2=A0 The byte compiler has much more accurate iden= tification of docstrings that can be relied on when using the bootstrap ema= cs to byte compile files to be pre-loaded.
Another a= pproach would to eliminate the special treatment by the reader altogether t= o the extent it only saves space in the bootstrap dump, then rely on lazy l= oading from byte-compiled files for docstrings in lisp files.=C2=A0 That mi= ght require evicting those docstrings during the first post-bootstrap dump,= or just eliminating them from the function symbol property during the boot= strap dump, since who is using the help system in the bootstrap emacs?

Lynn
=
--000000000000f3872105e5056930--