unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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.



  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).