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

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Alan Mackenzie [2023-10-30 09:44:54] wrote:
> Thus far, all you've done is disparage every design decision I've made
> with this code, saying how you would have done it differently, without
> giving any justification for why your way would be better.  How am I
> meant to react?

Thanks for putting into words how I feel :-)

> Not yet.  Putting complicated stuff into backtrace code is a bad idea -
> look what happened when cl-print got put into debug-early.el.  Bugs.

Bootstrap problems are rare, and difficult to predict, so we fix them in
a reactive way.  Debugging a bootstrap is generally more difficult.
That's also true when trying to debug GDB (the usual answer is to use
another GDB, and in Emacs you can do the same: debug from another
debugger, such as GDB, rather than from the built-in debugger).

We shouldn't design the featureset for the corner case of when the
bootstrap fails, because it is a very small fraction of the use-cases,
that 99.99% of Emacs users never face.

>> > Forcing a user to look somewhere else for pertinent information can
>> > only increase that level of stress.
>> Any concrete evidence to back this claim?
> Of course not.  Just as you've got no evidence to back up the contrary.

Fist, I did not make a claim to the contrary, so the burden of proof is
not on me.  This said, I believe there is ample evidence out there,
because all the programming tools I've ever used try first and foremost
to let you jump to the corresponding source code.  The source code is
what programmers are familiar with, so being able to jump from the
backtrace to the corresponding source code is generally the best known
way to help the user find the pertinent info.

From the FILE+LINE+COL info the user can recover the info your patch
provides, but the reverse is generally not true.  Of course, there is
the exception of when the source code has been changed or is missing or
somesuch, but I don't think we should consider those cases when
designing the featureset either, because here as well, this is expected
to be a fringe case.

>> Then why do you presume we'd be so stupid as to include the full
>> absolute file name in there?
> That falls outside the bounds of acceptable GNU mailing list language.

Yes, I was aware of it.  I just wasn't able to refrain from venting my
frustration: criticizing my suggestion based on the fact that the full
file name is too long falls squarely in the category of "strawman
argument".

>> > Besides which, you'd need to store all the pertinent information, the
>> > filename + line + column in RAM, probably in the subr or the byte
>> > coded function.
>> I already told you where we'd store that info.  Not in RAM.
> So with all the extra complexity you want to add, you'll risk getting a
> recursive error and recursive backtrace.

I want the better info, even if that means a slight increase in
complexity and the associated risk that I have to go and fix a bug in
that code next year, yes.

> You haven't made any attempt to justify this, to my mind, questionable
> design.

Hmm... I'd return the compliment :-)

> Which looks like you intend to strip it out, leaving interpreted code as
> a special case without the instrumentation.

Yes.

>> So it'll always be a best effort, where we try and cover the important cases.
> Which is a good deal better than the current state of affairs.

But as it currently stands, it comes at some costs:
- changing the syntax of `lambda`.
- changing the representation of functions (both bytecode and interpreted).
- added runtime costs even when the feature unused (no `C-h v`, no
  backtraces), which is the most likely use-case.

Storing the info in the docstring would fix the second and third point.
Using the FILE+LINE+COL info would fix the first.

>> > I still believe that the defining symbol scheme is the most practical
>> > way of conveying the needed extra information to the user.
>> Obviously.
>> > Otherwise I would have hacked something different.  ;-)
>> I don't think that's how it works, sadly.
> What are you talking about with "that"?

I have the impression that you're defending your design because that's
what you've coded.  :-(


        Stefan