From: "Clément Pit-Claudel" <cpitclaudel@gmail.com>
To: emacs-devel@gnu.org
Subject: Re: Correct line/column numbers in byte compiler messages [Was: GNU is looking for Google Summer of Code Projects]
Date: Fri, 20 Mar 2020 17:27:34 -0400 [thread overview]
Message-ID: <a8d939b2-b2f8-c846-69cc-bfeb04673400@gmail.com> (raw)
In-Reply-To: <20200320201005.GC5255@ACM>
On 20/03/2020 16.10, Alan Mackenzie wrote:
> Are you saying that this is how other Lisp compilers deal with
> source code positions? How do they deal with the difficult problem
> of user macros? Could you give me an example of a free Lisp system
> which works this way? I'd be interested in having a look at it.
not sure if it counts as a Lisp compiler, but Racket does this; the "fat cons cells" are called syntax objects. See https://blog.racket-lang.org/2011/04/writing-syntax-case-macros.html for a good explanation, including this intro:
> The main idea with Racket’s macro system (and with other syntax-case
> systems) is that macros are syntax-to-syntax functions, just like the
> case of defmacro, except that instead of raw S-expressions you’re
> dealing with syntax objects. This becomes very noticeable when
> identifiers are handled: instead of dealing with plain symbols,
> you’re dealing with these syntax values (called “identifiers” in this
> case) that are essentially a symbol and some opaque information that
> represents the lexical scope for its source. In several syntax-case
> systems this is the only difference from defmacro macros, but in the
> Racket case this applies to everything — identifiers, numbers, other
> immediate constants, and even function applications, etc — they are
> all the same S-expression values that you’re used to, except wrapped
> with additional information. Another thing that is unique to Racket
> is the extra information: in addition to the opaque lexical context,
> there is also source information and arbitrary properties (there are
> also certificates, but that’s ignorable for this text).
It would be worth checking more closely what Guile does. Its syntax-manipulating functions automatically propagate "source properties", but from reading https://www.gnu.org/software/guile/manual/html_node/Source-Properties.html it seems that it might use something similar to your approach?
Clément.
next prev parent reply other threads:[~2020-03-20 21:27 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-19 15:10 GNU is looking for Google Summer of Code Projects Rocky Bernstein
2020-03-19 17:35 ` Stefan Monnier
2020-03-19 17:56 ` Andrea Corallo
2020-03-19 18:05 ` Andrea Corallo
2020-03-19 18:19 ` Rocky Bernstein
2020-03-19 21:26 ` Stefan Monnier
2020-03-19 21:45 ` Andrea Corallo
2020-03-19 23:07 ` Rocky Bernstein
2020-03-19 20:34 ` Correct line/column numbers in byte compiler messages [Was: GNU is looking for Google Summer of Code Projects] Alan Mackenzie
2020-03-19 20:43 ` Andrea Corallo
2020-03-20 19:18 ` Alan Mackenzie
2020-03-21 11:22 ` Andrea Corallo
2020-03-21 15:30 ` Correct line/column numbers in byte compiler messages Alan Mackenzie
2020-03-21 16:28 ` Andrea Corallo
2020-03-21 18:37 ` Andrea Corallo
2020-03-21 20:19 ` Alan Mackenzie
2020-03-21 21:08 ` Andrea Corallo
2020-03-21 23:39 ` Andrea Corallo
2020-03-22 11:26 ` Alan Mackenzie
2020-03-19 20:56 ` Correct line/column numbers in byte compiler messages [Was: GNU is looking for Google Summer of Code Projects] Rocky Bernstein
2020-03-19 22:05 ` Stefan Monnier
2020-03-20 19:25 ` Alan Mackenzie
2020-03-19 21:41 ` Stefan Monnier
2020-03-19 22:09 ` Stefan Monnier
2020-03-20 20:10 ` Alan Mackenzie
2020-03-20 21:23 ` Rocky Bernstein
2020-03-20 21:27 ` Clément Pit-Claudel [this message]
2020-03-20 23:46 ` Stefan Monnier
2020-03-20 21:30 ` Stefan Monnier
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a8d939b2-b2f8-c846-69cc-bfeb04673400@gmail.com \
--to=cpitclaudel@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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).