From: Helmut Eller <eller.helmut@gmail.com>
To: emacs-devel@gnu.org
Subject: Re: Thoughts on the buffer positions in the byte compiler's warning messages.
Date: Sun, 18 Sep 2016 20:21:46 +0200 [thread overview]
Message-ID: <m2inttcblx.fsf@gmail.com> (raw)
In-Reply-To: 20160918152303.GA3576@acm.fritz.box
On Sun, Sep 18 2016, Alan Mackenzie wrote:
> After the reader has produced the form to be compiled and
> read-symbol-positions-list, we combine these to produce a @dfn{shadow
> form} with the same shape as the form, but where there's a symbol in the
> form, there is a corresponding list in the shadow form, noting the
> corresponding "position" in the form, and onto which warning/error
> messages can be pushed. These can then be output at the end of the
> compilation.
It would be problematic to pass such shadow-forms to macros because
macros would be confused if they see artificial lists where they expect
symbols. After macro expansion that's no longer a problem and the
compiler can use any representation that is convenient.
So, instead of replacing symbols with lists, I would attach the position
to cons cells (stored in an auxiliary hashtable with the cons as key).
(Remember that in Lisp code almost every symbol is stored in the car of
of a cons.)
> Comments?
First, I would look at CMUCL or Clozure CL for inspiration. Those
compilers produce fairly accurate source location information and also
have the problem that they need to pass "vanilla" forms to macros.
(Scheme compilers use "syntax-objects" instead of vanilla forms, so
there's probably not much to learn there.)
Second, instead of (or in addition to) recording the position of symbols
in read-symbol-positions-list I would record the start and end position
of lists ie. the READ function should record the position of "(" and the
corresponding ")" for each list.
Third, MACROEXPAND should record source forms so that the compiler can
list all forms (and positions) that eventually generated the fully
expanded form.
Fourth, for very sophisticated macros there should probably be some API
beyond MACROEXPAND so that macros can help the compiler to track source
positions.
Helmut
prev parent reply other threads:[~2016-09-18 18:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-18 15:23 Thoughts on the buffer positions in the byte compiler's warning messages Alan Mackenzie
2016-09-18 17:38 ` Alan Mackenzie
2016-10-13 22:58 ` Andreas Politz
2016-09-18 18:21 ` Helmut Eller [this message]
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=m2inttcblx.fsf@gmail.com \
--to=eller.helmut@gmail.com \
--cc=emacs-devel@gnu.org \
/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.