From: Paul Eggert <eggert@cs.ucla.edu>
To: Alan Mackenzie <acm@muc.de>
Cc: michael_heerdegen@web.de, Eli Zaretskii <eliz@gnu.org>,
emacs-devel@gnu.org, cpitclaudel@gmail.com,
monnier@IRO.UMontreal.CA
Subject: Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstraps.
Date: Tue, 27 Nov 2018 17:11:48 -0800 [thread overview]
Message-ID: <23334086-c0a1-7b34-4234-343719618bd1@cs.ucla.edu> (raw)
In-Reply-To: <20181127215347.GC4705@ACM>
On 11/27/18 1:53 PM, Alan Mackenzie wrote:
> Macros would mess things up. For example, after expanding a macro like
> the contrived
> (defmacro dehash (form)
> (copy-tree form))
>
> , how would the recorded cons locations be linked up with the resulting
> form?
People typically don't write macros like that, so we needn't tune our
design for it. More commonly, people write macros containing errors,
such as:
(defmacro face-attribute-specified-or (value default &rest body)
(let ((temp (make-symbol "value")))
`(or
(let ((,temp ,value))
(if (eq ,temp 'unspecified)
(progn ,@body)
default))
,temp)))
This has a parenthesization typo and the macro doesn't mean what the
user probably intended. For these macros, as I understand it the
symbols-with-pos approach messes up because the symbol associated with
the error was built by make-symbol and doesn't have a source code
position. In contrast, the cons-with-pos approach should return a good
location in the macro itself for the undeclared symbol (i.e., just
before the last ",temp").
One can also come up with examples where the symbols-with-pos approach
is better than the cons-with-pos approach. That is, neither approach
dominates the other. So, which approach would be better in practice? I
don't think we know.
> the "slow" Emacs would somehow need to be used by the byte compiler
> after Emacs has been built, to continue to get accurate warning locations.
That's easy enough: the fast Emacs can fork and exec the slow one, which
can be installed next to movemail etc. (Again, not that I like this
approach.)
next prev parent reply other threads:[~2018-11-28 1:11 UTC|newest]
Thread overview: 110+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-17 12:45 scratch/accurate-warning-pos: First tentative successes Alan Mackenzie
2018-11-17 13:13 ` Eli Zaretskii
2018-11-23 13:09 ` scratch/accurate-warning-pos: Solid progress: the branch now bootstraps Alan Mackenzie
2018-11-25 11:26 ` Charles A. Roelli
2018-11-25 14:31 ` Alan Mackenzie
2018-11-25 15:12 ` Andreas Schwab
2018-11-25 15:42 ` Alan Mackenzie
2018-11-25 16:40 ` Eli Zaretskii
2018-11-25 17:59 ` Alan Mackenzie
2018-11-25 18:15 ` Eli Zaretskii
2018-11-25 18:23 ` Alan Mackenzie
2018-11-25 19:36 ` Alan Mackenzie
2018-11-25 16:22 ` Stefan Monnier
2018-11-25 17:35 ` Alan Mackenzie
2018-11-25 18:22 ` Stefan Monnier
2018-11-25 19:54 ` Alan Mackenzie
2018-11-25 20:08 ` Stefan Monnier
2018-11-26 9:52 ` Alan Mackenzie
2018-11-26 10:16 ` Alan Mackenzie
2018-11-25 16:38 ` Eli Zaretskii
2018-11-25 17:27 ` Andreas Schwab
2018-11-25 17:31 ` Alan Mackenzie
2018-11-25 17:39 ` Eli Zaretskii
2018-11-25 18:08 ` Alan Mackenzie
2018-11-25 18:45 ` Paul Eggert
2018-11-25 19:30 ` Alan Mackenzie
2018-11-25 20:12 ` Paul Eggert
2018-11-25 21:29 ` Alan Mackenzie
2018-11-26 1:41 ` Paul Eggert
2018-11-26 3:41 ` Eli Zaretskii
2018-11-26 17:43 ` Paul Eggert
2018-11-26 18:43 ` Alan Mackenzie
2018-11-26 19:18 ` Clément Pit-Claudel
2018-11-26 19:42 ` Alan Mackenzie
2018-11-27 1:07 ` Gemini Lasswell
2018-11-27 1:45 ` Alan Mackenzie
2018-11-27 6:06 ` Eli Zaretskii
2018-11-27 2:48 ` Paul Eggert
2018-11-27 7:43 ` Alan Mackenzie
2018-11-27 20:27 ` Paul Eggert
2018-11-27 21:15 ` Alan Mackenzie
2018-11-27 21:37 ` Paul Eggert
2018-11-27 21:53 ` Alan Mackenzie
2018-11-28 1:11 ` Paul Eggert [this message]
2018-11-28 12:04 ` Alan Mackenzie
2018-11-29 21:28 ` Paul Eggert
2018-11-29 22:05 ` Alan Mackenzie
2018-11-30 17:50 ` Paul Eggert
2018-11-30 18:55 ` Alan Mackenzie
2018-11-30 20:14 ` Paul Eggert
2018-11-30 22:02 ` Alan Mackenzie
2018-11-30 23:46 ` Paul Eggert
2018-12-01 7:35 ` martin rudalics
2018-12-01 8:25 ` Eli Zaretskii
2018-12-01 11:08 ` Alan Mackenzie
2018-12-01 11:36 ` Eli Zaretskii
2018-12-01 12:47 ` Alan Mackenzie
2018-12-01 14:09 ` martin rudalics
2018-12-01 14:30 ` Stefan Monnier
2018-12-01 16:30 ` martin rudalics
2018-12-01 19:56 ` Stefan Monnier
2018-12-01 14:59 ` Eli Zaretskii
2018-12-01 16:31 ` martin rudalics
2018-12-01 16:53 ` Eli Zaretskii
2018-12-01 19:04 ` martin rudalics
2018-12-01 19:22 ` Eli Zaretskii
2018-12-01 17:21 ` Alan Mackenzie
2018-12-01 17:44 ` Michael Heerdegen
2018-12-01 18:58 ` Alan Mackenzie
2018-12-01 20:26 ` Alan Mackenzie
2018-12-01 17:48 ` Eli Zaretskii
2018-12-01 21:00 ` Paul Eggert
2018-12-01 17:50 ` Clément Pit-Claudel
2018-12-01 18:26 ` Yuri Khan
2018-12-01 19:15 ` Clément Pit-Claudel
2018-12-01 21:26 ` Paul Eggert
2018-12-02 6:48 ` Yuri Khan
2018-12-02 18:39 ` Gemini Lasswell
2018-12-03 2:28 ` Stefan Monnier
2018-12-01 19:04 ` martin rudalics
2018-12-02 22:53 ` Dmitry Gutov
2018-12-01 0:26 ` Gemini Lasswell
2018-12-01 11:48 ` Alan Mackenzie
2018-11-27 22:09 ` Stefan Monnier
2018-11-28 2:18 ` Paul Eggert
2018-11-28 2:43 ` Stefan Monnier
2018-11-28 5:13 ` Paul Eggert
2018-11-28 6:03 ` Gemini Lasswell
2018-11-28 5:39 ` Gemini Lasswell
2018-11-28 13:06 ` Stefan Monnier
2018-11-28 6:28 ` Eli Zaretskii
2018-11-28 22:50 ` Paul Eggert
2018-11-29 7:19 ` Eli Zaretskii
2018-11-29 10:54 ` Alan Mackenzie
2018-11-29 11:13 ` Eli Zaretskii
2018-11-29 11:37 ` Alan Mackenzie
2018-11-29 21:12 ` Paul Eggert
2018-11-29 21:28 ` Alan Mackenzie
2018-11-28 0:53 ` Gemini Lasswell
2018-11-26 20:04 ` Stefan Monnier
2018-11-27 2:51 ` Paul Eggert
2018-11-26 9:48 ` Alan Mackenzie
2018-11-26 18:27 ` Paul Eggert
2018-11-25 18:48 ` Gemini Lasswell
2018-11-25 20:02 ` Stefan Monnier
2018-11-26 12:39 ` Alan Mackenzie
2018-11-26 16:14 ` Gemini Lasswell
2018-11-26 17:06 ` Alan Mackenzie
2018-11-26 17:24 ` Alan Mackenzie
2018-11-29 12:26 ` scratch/accurate-warning-pos: Some real world timings Alan Mackenzie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=23334086-c0a1-7b34-4234-343719618bd1@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=acm@muc.de \
--cc=cpitclaudel@gmail.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=michael_heerdegen@web.de \
--cc=monnier@IRO.UMontreal.CA \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.