From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.) Date: Thu, 28 Mar 2024 12:25:11 -0400 Message-ID: References: Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24643"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , 67455@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Mar 28 17:26:29 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1rpsaD-0006B3-G4 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 28 Mar 2024 17:26:29 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rpsZo-0002m7-Ft; Thu, 28 Mar 2024 12:26:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rpsZl-0002lh-Tz for bug-gnu-emacs@gnu.org; Thu, 28 Mar 2024 12:26:01 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rpsZl-0000WX-Bg for bug-gnu-emacs@gnu.org; Thu, 28 Mar 2024 12:26:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rpsZl-0006Dt-P7 for bug-gnu-emacs@gnu.org; Thu, 28 Mar 2024 12:26:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 28 Mar 2024 16:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67455 X-GNU-PR-Package: emacs Original-Received: via spool by 67455-submit@debbugs.gnu.org id=B67455.171164313323878 (code B ref 67455); Thu, 28 Mar 2024 16:26:01 +0000 Original-Received: (at 67455) by debbugs.gnu.org; 28 Mar 2024 16:25:33 +0000 Original-Received: from localhost ([127.0.0.1]:41012 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rpsZI-0006D3-9D for submit@debbugs.gnu.org; Thu, 28 Mar 2024 12:25:32 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:48304) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rpsZE-0006CL-Ci for 67455@debbugs.gnu.org; Thu, 28 Mar 2024 12:25:30 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 71ECA4429C0; Thu, 28 Mar 2024 12:25:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1711643119; bh=BpvhuISHjL0jGFojQFdesEy+N+/FupKVVq9t5IXvgzI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=XK7Oscplr07xbbdJ2/1jmDpKqXw4nsK5DgrpYpY4/bQk9pvTROUQ0ZhicOkHqU2wu XV0XicUbfoozmcAHM6KXyOwBvYT0ZTy2lZaQqOfb1p03OXltA0jOmgaV2GOtRVMVgU 6AE7me7xDv1j3AFbq/x+8+/dW273VvELUpMga6227pvqVyxNvk5dmQEaMy+Voz7GUQ FDlC8OA2l3oT43+vy2PCGD9EHfCosylIWwJURjOOniNUBzxIdgisgfsdjoFeb69ZLj DJj8XYX0RiH/VPobs+bbNz83s26ZhzEoYmlISTECWe4vATvv8qROSZEhh+EE2JA7CB tjf8MbLYzsqWA== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 222D44429C4; Thu, 28 Mar 2024 12:25:19 -0400 (EDT) Original-Received: from pastel (unknown [45.72.199.112]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id F16071207EA; Thu, 28 Mar 2024 12:25:18 -0400 (EDT) In-Reply-To: (Alan Mackenzie's message of "Wed, 27 Mar 2024 21:43:29 +0000") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:282239 Archived-At: > I think it is better to regard the byte compilation as the special case. > Only in byte compilation do we want to preserve the SWPs on forms > getting posified. [...] > Byte compilation is NOT calling loading from source. We don't have a > caller/callee relationship here. We are doing posification either from The "callee" I'm talking about is `load-source-file-function` (which is instead another "caller", beside the byte compiler), it is the code that tests `byte-compile-in-progress`. Based on the above two elements, I suggest the name `macroexp--inhibit-strip-sympos` (and set/pass/bind it as needed in the compiler). [ FWIW, the reason I associate this variable with `load-source-file-function` rather than with the compiler is because the macroexp code which tests this variable only strips the SWPs at a very few different spots, more specifically those very spots that are expected to get SWPs in the `load-source-file-function`. Different minds work differently, I guess. =F0=9F=99=82 ] >> Also, I think as a general rule it's better for the caller to set >> a callee variable that controls how the callee behaves, rather than for = the >> callee to check a caller variable to decide how to behave, because >> it's normal for the caller to "know about" its callee (after all, it's >> the caller which decides to call the callee), whereas it's not normal >> for the callee to know about specific callers (it creates undesirable >> dependencies). > byte compilation or from somewhere else. It is analogous to testing > lexical binding. Here, the variable is called lexical-binding; it is > not named after a particular activity to be carried out differently for > l-b and not l-b. Indeed testing `lexical-binding` in macros (like we do at a few places) sucks; it's an ugly hack. We use it because that was the least bad option we could come up with given the need to preserve backward compatibility. Here there's no such problem. >> The earlier the better, in theory, but not at any cost. > No, the earlier the better, full stop. Please "full stop" being absolutist. We're talking about opinions and preferences here. When hitting an error, I spend more time reading the code (and modifying it) than looking at debug output, so to me the clarity of the code is more important than whether a few lambdas get some addition positional info, especially since I usually know full well where those lambdas come from. I understand it affects us differently, but the tradeoff is real. >> Having to write all that code within the very restrictive sublanguage >> available before subr.el and backquote.el is a cost I don't think >> justifies it. > The cost has already been paid, by me. Code is not "fire and forget". >> >> My crystal ball suggests that "currently" may be the wrong way to thi= nk >> >> about it: maybe instead of thinking of "when" (as in "during the >> >> definition of function FOO") what you're looking for might be "where" >> >> (as in "within the body of FOO"). >> >> [ That's the same difference as the difference between dynamic and >> >> static scoping. ] >> > I'm having trouble understanding what you're saying, here. >> Is it because you don't understand the difference between dynamic >> scoping and static scoping, or because you don't see the relationship >> with that and your notion of "currently being defined"? > The latter, I think. defining-symbol is entirely dynamically scoped. We're still miscommunicating. You're talking about how your code is implemented, apparently, whereas I'm asking about what is the intended behavior. It's like I'm asking what the C spec says and you're answering me by telling me how GCC works. > I'm convinced it does. Can you suggest a scenario where the > defining-symbol mechanism (outlined above) might fail? Without knowing what it is intended to do, the only thing we can say is that it does what it does, so no indeed it won't fail to do what it does, since that's what it does. =F0=9F=99=82 >> >> Do you have rough numbers comparing the cost of `read`, >> >> `read-positioning-symbols`, and `read-positioning-DEFINED-symbols`? >> > No, but they will be very close to eachother (and very cheap) >> Then I think we should use `read-positioning-symbols`, which >> requires fewer code changes. > It won't. Required would be Lisp code to determine whether a particular > SWP needs to be stripped or not. This is not going to be simple. It is > likely to be about as complicated as the existing enhancements to read0. They'd all need to be stripped, AFAICT, so we'd do: (strip-all-symbol-positions (macroexp--expand-all (read-positioning-symbols))) What would be hard about it? >> >> Also, IIUC you don't have a separate phase to strip the SWPs when >> >> loading from source, but instead you strip them as you "consume" their >> >> info during macroexpansion. If so, how/when/where do you strip the >> >> false positives that may occur inside quoted data or in code like: > >> >> (defmacro foo (lambda bar) ...) >> >> (defmacro foo (defun bar) ...) > >> >> (let* ((lambda foo) >> >> (defun bar)) >> >> ...) > >> > There's a pcase arm right at the end of macroexp--expand-all which str= ips >> > SWPs of their positions. Recursing through macroexp--all-forms will >> > eventually hit this pcase arm for these lambdas. Actually, now that I look at the code I only see: ((guard (and (not byte-compile-in-progress) (symbol-with-pos-p form))) (bare-symbol form)) is that the "arm" you're talking about? AFAICT this will handle only those symbols which appear as Lisp expressions (IOW symbols which are variable references), so it will strip the `bar` in the second example but not the `bar` in my first exmple, nor the two `lambda`s, nor those in '(lambda (defun bar)) >> But your current code in byte-run.el is a Bad Thing as well. > What, precisely, do you find bad about it? It may be possible to improve > it without wholesale redesign. A lot of it is hard to read because it is constrained to a restrictive subset of ELisp. >> I'm not suggesting to drop support for lambdas loaded from source. >> I'm saying we don't need to support it for the first N files loaded into >> `src/emacs-bootstrap`. > You're suggesting dropping support for many source files, where that > support is most needed. "Most needed" according to which criteria? > I'm not playing on words. My point is that > read-positioning-defined-symbols exists and works. It is not a > speculative "would be nice to have". The work has already been done. Code costs by merely existing. > Why do you think this design change will be better than the existing > design? I don't actually know whether it will be better. It just seems it could lead to simpler code, with no change at all to the reader, for example. I'm here asking what lead you to the current design, under the assumption that the complexity you introduced was the result of other experiments. Am I to understand that the current code is basically your first attempt at adding such functionality? Stefan