[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Correct line/column numbers in byte compiler messages [Was: GNU is l
From: |
Clément Pit-Claudel |
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 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 |
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.
- Re: Correct line/column numbers in byte compiler messages, (continued)
- Re: Correct line/column numbers in byte compiler messages, Alan Mackenzie, 2020/03/22
- Re: Correct line/column numbers in byte compiler messages [Was: GNU is looking for Google Summer of Code Projects], Rocky Bernstein, 2020/03/19
- Re: Correct line/column numbers in byte compiler messages [Was: GNU is looking for Google Summer of Code Projects], Stefan Monnier, 2020/03/19
- Re: Correct line/column numbers in byte compiler messages [Was: GNU is looking for Google Summer of Code Projects], Alan Mackenzie, 2020/03/20
- Re: Correct line/column numbers in byte compiler messages [Was: GNU is looking for Google Summer of Code Projects], Stefan Monnier, 2020/03/19
- Re: Correct line/column numbers in byte compiler messages [Was: GNU is looking for Google Summer of Code Projects], Stefan Monnier, 2020/03/19
- Re: Correct line/column numbers in byte compiler messages [Was: GNU is looking for Google Summer of Code Projects], Alan Mackenzie, 2020/03/20
- Re: Correct line/column numbers in byte compiler messages [Was: GNU is looking for Google Summer of Code Projects], Rocky Bernstein, 2020/03/20
- Re: Correct line/column numbers in byte compiler messages [Was: GNU is looking for Google Summer of Code Projects],
Clément Pit-Claudel <=
- Re: Correct line/column numbers in byte compiler messages [Was: GNU is looking for Google Summer of Code Projects], Stefan Monnier, 2020/03/20
- Re: Correct line/column numbers in byte compiler messages [Was: GNU is looking for Google Summer of Code Projects], Stefan Monnier, 2020/03/20
Re: GNU is looking for Google Summer of Code Projects, Zhu Zihao, 2020/03/22