bug#66750: Unhelpful text in C-h v for variables with a lambda form as value

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Sun, Oct 29, 2023 at 00:14:24 -0400, Stefan Monnier wrote:
> >> > There are lots of detailed changes in eval.c and bytecomp.el (and
> >> > friends).  Also the macro `lambda' in subr.el has been amended to insert
> >> > the current global defining-symbol if there isn't already a non-nil
> >> > symbol in that position.
> >> So the source code can manually provide this extra symbol in `lambda`?
> >> Where have you found that useful?
> > The first few functions in debug-early.el and byte-run.el, for a start.
> > There, there is not yet a defmacro macro.  Also in
> > comp-trampoline-compile, where there doesn't seem to be any other way to
> > get the name of the primitive into the defining symbol.  I think there'll
> > be quite a few other places, too.

> Hmm... it seems like keeping the LINE+COL info rather than
> a surrounding definition would be better in this regard since it wouldn't
> require any changes at all to the actual lambdas, regardless where
> they are.

I don't agree with this.  Whether we add FILE+LINE+COL info is to a
large degree a separate question from that of adding defining symbol
info.

If you don't add information to the actual lambda, then that information
won't be available when that lambda turns up in a backtrace or as a
value in C-h v.  Surely you'd have to keep FILE+LINE+COL in the lambda
itself, somehow.

That also assumes that the source file will be available and unchanged
when it's needed.

It will also stress the user somewhat, since it will force her to look
up a file location to get any idea of what is failing.  A defining
symbol is much more immediately useful, even if it may not be 100%
dependable because of the issues you raise below.

> >> Hmm... as a user, rather than the enclosing definition I think I'd
> >> expect to get some kind of source information like FILE+LINE+COL.
> > Possibly: either is a good deal better than what we have at the moment.

> The notion of "surrounding definition" is less precise (there can be
> several lambdas inside a given definition, there can be lambdas outside
> of any definition, ...).

Yes, there can be several lambdas in a function, though I don't think
this is common.  Certainly it hasn't given me any problems in use, so
far.  But lambdas outside of definitions?  I doubt very much there are
any in the Emacs sources, or even in the packages.

Or are you thinking about something like an explicit (defalias foo
(lambda (..) ...))?

> Furthermore, that info is already available to the bytecompiler, so it's
> actually easier to keep that info.

How are you actually going to use this information?  What are you going
to print in a backtrace, in particular in a batch mode backtrace where
things like buttons are not useful?

For that matter, what are you going to print in that C-h v example?

> >> Actually, the bytecode functions can already keep the FILE info (in
> >> the form of the (FILE . OFFSET) cons cell in the docstring slot of the
> >> bytecode object), we just opt never to expose that FILE info to the user
> >> (we only use it to fetch the actual docstring).
> > That's the offset in the .elc file, though, not the source.

> Yup.  [ Tho now that you make me think about it, if we want to be cheap,
> we could go to that OFFSET position and look around for a `^(defalias`
> and that might be sufficient to give us "the surrounding definition" in
> many cases :-)  ]

That doesn't sound systematic, or at all attractive.  ;-)

> >> [ Tho, admittedly, it's also that the byte-compiler only uses such
> >>   (FILE . OFFSET) for named functions, but it wouldn't be hard to change.  ]
> >> As for how/where to store the LINE+COL, I guess (aref form 5) is still
> >> an option, although, maybe we should store that info alongside the
> >> docstring, like we already do for the arglist.
> > Well, the doc string is at (aref form 4).  :-)

> What I meant is that the docstring is in the `.elc` file.  So the
> bytecode object would be literally unchanged, it's just that the
> bytes found at OFFSET inside FILE would be extended to hold:
> - the docstring
> - the human-readable arglist
> - the LINE+COL info

Don't forget, all this info would have to go into .eln files too,
probably in the struct Lisp_Subr.  It would be better if it were also
somehow available in uncompiled lambdas, something which is needed for
debugging failures in early bootstrapping.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).