emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposal: stack traces with line numbers


From: Helmut Eller
Subject: Re: Proposal: stack traces with line numbers
Date: Sun, 15 Oct 2017 12:01:01 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

On Sat, Oct 14 2017, John Williams wrote:

> 1. Revise the reader to attach source references (i.e. filename, line
> number, and column number) to forms as they are read.  [...]

This part would be useful not just for backtraces, but also for improved
source positions in compiler messages.  And in general for users who use
the reader without the compiler.

> The information is "attached"
> using cons cells as keys in a weak-key hash table.  [...]

Unless you care about interpreted code, a non-weak hash-table should be
enough.  I think this hash table should work similar to
read-symbol-positions-list.

> - I'm storing the information in vectors because it seems like a
> reasonably efficient use of memory. [...]

It's debatable whether a [file line column] vector is an efficent
representation.  E.g. all lists in a source form come from the same file
(or buffer or string) so storing the same filename many times seems
redundant.  It might also be reasonable to use different representations
in the debug info than for the data-structures used by the reader or
compiler.

> - I'm saving line and column numbers rather that just byte/character
> offsets [...]

Line/column pairs have the (minor) advantage that line numbers have a
higher porbability to stay the same after small edits to the source.
But other than that, it seems to me that character offsets encode the
same information more compactly.

> - I'm only attaching information to the head of each list purely as a
> memory-saving measure. I can't think of scenario where you'd need a
> source reference for a list without having its head available, except
> maybe in the expansion of a macro that disassembles its arguments and
> puts them back together in a new list.  If it's an issue in practice,

In Lisp almost everything is a macro, so I bet that this is an issue.

> I think a better solution would be for the macro expander to propagate
> source refs to every cons cell in a macro argument at the point where
> macro expansion takes place.

It's clearly desirable that source positions are propagated
automatically as often as possible.  That job will be easier if the
reader records more information.

So, I think the reader should, at least optionally, also record
positions of every cons cell not just the first in a list.  Also, in
addition to the start position the reader could/should also record the
end position.

Helmut




reply via email to

[Prev in Thread] Current Thread [Next in Thread]