Re: Thoughts on getting correct line numbers in the byte compiler's warning messages

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Thu, Nov 08, 2018 at 12:02:01 -0500, Stefan Monnier wrote:
> >> >> It's "only" the cconv-convert part of cconv.el that will need changes,
> >> >> but yes, one way or another it will need to be changed to preserve the
> >> >> location info.
> >> > OK.  But it's still a challenging job.
> >> I wouldn't call it challenging: the changes are orthogonal to the actual
> >> working of cconv, so it will likely make the code messier but
> >> conceptually there's no significant difficulty.  I'm familiar with the
> >> code and will be happy to help.
> > Thanks!  By the way, am I right in thinking that pcase does its
> > comparisons using equal?

> "as if by `equal`", so when comparing against symbols we actually use `eq`.

... at the moment ... ;-)

equal actually tests EQ right near its start anyway, so it shouldn't be
a big deal for pcase actually to use equal.  Or am I missing something?

> > One thing we'd need to watch out for is using equal, not eq, when we
> > compare symbols.  (eq 'foo #<symbol foo with position 73>) will surely
> > be nil, but (equal ....) would be t.  Same with member and memq.

> Indeed.

> > We'd also need to make sure that the reader's enabling flag for creating
> > these extended symbols is bound to nil whenever we suspend the byte
> > compiler to do something else (edebug, for example).

> Rather than a dynamically-scoped var, it might be a better option to
> either use a new function `read-with-positions`, or else use an
> additional argument to `read`.

OK.  I've hacked together some basic infrastructure in alloc.c, lread.c,
print.c, and lisp.h.  I can now read a small test file and get back the
form with "located symbols".  I've called the new function which does
this read-locating-symbols, but that might want to change.

As soon as I've sorted out SYMBOLP and XSYMBOL, I'll create a new branch
under /scratch, commit what I've got, and then we can play with it.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).