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: Wed, 27 Mar 2024 08:22:27 -0400 Message-ID: References: Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31646"; 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 Wed Mar 27 13:23:28 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 1rpSJT-00081U-9M for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 27 Mar 2024 13:23:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rpSJ8-0005Lw-A7; Wed, 27 Mar 2024 08:23:06 -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 1rpSJ4-0005Kr-K9 for bug-gnu-emacs@gnu.org; Wed, 27 Mar 2024 08:23:02 -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 1rpSJ4-0006Ft-AH for bug-gnu-emacs@gnu.org; Wed, 27 Mar 2024 08:23:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rpSJ4-0001bn-6h for bug-gnu-emacs@gnu.org; Wed, 27 Mar 2024 08:23:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 27 Mar 2024 12:23:02 +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.17115421636128 (code B ref 67455); Wed, 27 Mar 2024 12:23:02 +0000 Original-Received: (at 67455) by debbugs.gnu.org; 27 Mar 2024 12:22:43 +0000 Original-Received: from localhost ([127.0.0.1]:35919 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rpSIk-0001am-GW for submit@debbugs.gnu.org; Wed, 27 Mar 2024 08:22:43 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:1122) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rpSIg-0001aT-Sp for 67455@debbugs.gnu.org; Wed, 27 Mar 2024 08:22:40 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 5DBC744122C; Wed, 27 Mar 2024 08:22:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1711542150; bh=MtRMs6iilx23Cs1GZOHrslJRqmsvKsGhH4pbPr92Q9o=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=CFmlj53hlHbYoWhEraJ9VukQhG7BRNUqeRt+v7guvO7L8zyys3wORrhuM1MqV4BE1 LNQ1Ue7QaCQm/PmnbfXld2ehbF7AdMc493SDfJmozQdjOjeGjZUhC6GX3p07tVg/YB bBXiI2Bg4nzTCOTUe2dG6zf9pibdo1fLilgy6yj8enaXeFgRRYwfwjTLxEGNvjE4Ka j1O2WThuGBoIjBMN46A2V5JnapehFCwxRSpbH1ZRVQHoJT3ZVQ/uQv63YKcDwEkeg1 jPx3Eh4FNbOoG1jYPOVmNeZggoXmgJsuazNkZkfDzp/90xHVrxPhoPAKD9cEjp0Tkm eSaJkumYTGjCw== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id F25EB44121A; Wed, 27 Mar 2024 08:22:29 -0400 (EDT) Original-Received: from pastel (unknown [45.72.199.112]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id BDAAF1203BC; Wed, 27 Mar 2024 08:22:29 -0400 (EDT) In-Reply-To: (Alan Mackenzie's message of "Wed, 27 Mar 2024 10:04:03 +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:282134 Archived-At: > More precisely, to @dfn{posify} their containing forms by writing the > position information into their doc strings. We do this in the byte > compilation case, too. The difference is that in the "load from source" > case we want to strip the SWP, in byte compilation, we don't. [ Nitpick: in byte-compilation, we also do. We want to keep the SWPs longer, but in the end we also want to strip them away necause we don't want them in the resulting compiled code. ] > I don't think that is a good name. The byte compiler has no business > setting "internal" variables for the posification processing. Instead it > should announce it's running and expect the posification to respect that. > I think byte-compile-in-progress is a good name for this. AFAIK we want those SWPs stripped if and only if we're in a "load from source" case. The compilation case is one of those where we don't want to strip them, but it's not the only one, so the compiler should not do anything w.r.t to that. Instead it's the code that does the "load from source" which should set some indicator that stripping is requested. 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). >> Better yet: to avoid the problem of dynamic scope extending "too far" >> (i.e. accidentally applying to nested loads/evals/compile/...), you >> could put the relevant info into `macroexpand-all-environment`. >> [ That var is also dynamically bound, but we're already careful to >> rebind it when needed so it doesn't apply to nested uses >> of macroexpansion. ] > > That variable is only loaded in the 17th loaded Lisp file. The new > facility should be working at the earliest stages of loading Lisp, as it > does at the moment. The earlier the better, in theory, but not at any cost. 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. If we *really* want that, then we should explore other avenues, such as keeping pre-macroexpanded versions of the files (for bootstrapping purposes) but generating those files from files where a more normal coding style can be used. [ Something similar to the ldefs-boot.el. ] > Besides, macroexpand-all-environment is not > documented anywhere, what it is, what it's for, etc. Feel free to disregard my advice if you don't like it. I'm just pointing out that it's probably the tool which gives you the semantics you want. >> My crystal ball suggests that "currently" may be the wrong way to think >> 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 above citation is in the context of my question about what you mean by "currently" in: doc: /* The symbol currently being defined by a defining form. I personally don't really understand it, and AFAICT, you don't really understand it either because you haven't been able to describe it. >> > Ideally, I would like to have bound defining-symbol inside defun. > >> (defmacro my-defun (name args &rest body) >> `(cl-macrolet ((defining-symbol () '',name)) >> (defun ,name ,args ,@body))) > >> (my-defun my-foo (x) (list x (defining-symbol))) > >> (symbol-function 'my-foo) >> ==> #f(lambda (x) [t] (list x 'my-foo)) > >> `cl-macrolet` uses `macroexpand-all-environment` for that. > > cl-macs gets loaded far too late for such an approach to be useful. That's not really relevant since we're just trying to understand what you mean by "currently". What is relevant is whether it gives the intended semantics. But if you insist, here's the equivalent version without `cl-macs` (using the same underlying technique as used by `cl-macrolet`): (defmacro my-defun (name args &rest body) (macroexpand-all `(defun ,name ,args ,@body) (cons (cons 'defining-symbol (lambda () `',name)) macroexpand-all-environment))) >> 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. >> 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 strips > SWPs of their positions. Recursing through macroexp--all-forms will > eventually hit this pcase arm for these lambdas. Ah, so it's like a "strip phase" but "fused" into the macroexpansion phase. >> Not at all. Those will remain without position, but only in >> `src/bootstrap-emacs`. > This would be a Bad Thing. But your current code in byte-run.el is a Bad Thing as well. It's all a question of trade-offs :-( >> In the real `src/emacs` they will get the position because they'll come >> from the `.el[cn]` file and by the time we get compile those files >> `macro-declarations-alist` will be fully populated. > The understanding we reached in November was that loading from source > files would be handled, too. 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`. Stefan