Re: Correct line/column numbers in byte compiler messages [Was: GNU is looking for Google Summer of Code Projects]

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Thu, Mar 19, 2020 at 17:41:30 -0400, Stefan Monnier wrote:
> > things like cconv.el here).  More to the point, users' macros chew up and
> > spit out cons cells, and we have no control over them.  So whilst we
> > could, with a lot of tedious effort, clean up our own software to
> > preserve cons cells (believe me, I've tried), this would fail in users'
> > macros.

> I think fat-cons cells are cheap to implement (with (hopefully) no
> performance impact when not used .....

They may be cheap to implement in themselves, but adapting the entire
byte compiler and all our macros to the heavily restricted semantics
they would impose would be an enormous job.  I've tried something
similar, and gave up in exhaustion.

> or weird semantic artifacts like the fat-symbol approach you tried),

Er, not "tried" but "implemented", please.  The implementation was
complete, and was capable of bootstrapping Emacs with correct positions
for all the (then plentiful) warning messages.

> and can work 99.9% right in the long term with an incremental way to
> get there.

Where does this 99.9% come from?  How is this cons tracking you're
proposing supposed to work, when there are an infinite number of
occurrences of the likes of

    (cons (car form) (cdr form))

in our code?

> Furthermore it matches the "usual" way to deal with this problem, so
> there's very little doubt about whether it can work or not.

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.

I think there's quite a bit of doubt as to whether this could work
effectively in Emacs.  The way to dispel this doubt is for Somebody (tm)
to implement it.

> > Since then I've worked a fair bit on creating a "double" Emacs core,
> > one core being for normal use, the other for byte compiling.
> > There's a fair amount of work still to do on this, but I know how to
> > do it.  The problem is that I have been discouraged by the prospect
> > of having this solution vetoed too, since it will make Emacs quite a
> > bit bigger.

> I'd probably try to veto it, indeed.  It might be a good solution in
> the short-term but it'd just slow down our progress in the long term.

Fixing bugs slows down our progress?

To which the answer is to install the working solution pending the
implementation of something better, after which it can be superseded.
Somehow, even that strategy tends to get vetoed.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).