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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 2 Nov 2023 09:37:15 +0000
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 66750@debbugs.gnu.org,
>   acorallo@gnu.org, stefankangas@gmail.com, acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> What Stefan seems to be proposing does not accord with his previous
> paragraph.  He is proposing an implementation which would preclude
> extension to what he calls the "less common" cases - things like working
> in edebug and interpreted code in general, amongst others.

I'm not sure your conclusion above is correct.  But even if it is,
whether we want such extensions should be the subject of a separate
dedicated discussion, after implementing what caters to the important
cases, if an implementation that caters to all of them is much more
complicated (which seems to be the case here).  There's no reason to
reject a much simpler implementation just because it doesn't support
110% of the cases.

> > Alan, we are in the engineering business, where designing for the most
> > common case, before adjusting the design in small ways for less common
> > cases, is one of the important principles.
> 
> Another principle is not closing off future options.

That is secondary to the above.  Future options might require a
complete re-implementation, so the fact that the current
implementation doesn't support those future extensions is not
necessarily a fatal flaw.  It is just one disadvantage, which should
be weighed against its advantages.

> We're at the stage where there's working code, which already works for
> edebug, ERT backtraces, early-debug.el, and so on.  So why are we
> debating abstract design principles?

Because having a working code doesn't necessarily mean we should be
happy about it.

> > And this is the usual outcome of trying to solve _ALL_ cases from the
> > get-go, by focusing on the fringe ones.  Premature optimization and
> > all that.
> 
> I haven't focussed on fringe cases.  I've focussed on getting a uniform
> implementation without special cases.

The point I'm trying to make is that in your attempt to find an
implementation that covers everything you entered the area of the
proverbial diminishing returns, and the result is problematic in
several aspects.  Your objections to alternative ideas seems to come
from the argument that those ideas will fail to support some rare
cases, but I consider rejection of ideas on these grounds as wrong and
even invalid, because it sacrifices too much for too little.

> It would be nice if people actually tried out the code in practice before
> criticising.  So far, there's no indication anybody has done this.

Why do we need to try the code before discussing its obvious
implications on Emacs?  The issues that Stefan is raising are crystal
clear from just reading the code.

> > Alan, I'd appreciate if you rethink your approach to the
> > implementation with the above principles in mind.
> 
> I don't want to implement something which will only work most of the time
> for the easy to implement cases, and which precludes extension to the
> general case.  I'd welcome any suggestions for a mechanism which would be
> capable of extension to the general case.

Once again, such ideas are definitely welcome, but they are not an
"over-my-dead-body" kind of requirement.

> I think you've already decided not to merge feature/named-lambdas.  I'm
> not surprised, but it's a shame.

I didn't yet make any decision, because I still hope you will agree
with at least some of the arguments.  Or at least agree to some kind
or compromise, even if you keep your opinions.

> Debugging Emacs Lisp is frequently a horrible experience, with partial
> error messages which don't tell you exactly where an error occurred,
> don't tell you which primitive triggered an error, and frequently give
> truncated backtraces, if any at all, due to unwise condition-cases, and
> so on.

I disagree with "frequently" and "horrible".  My experience is
different, although I do sometimes need to be "creative" to catch some
errors.  But the existing tools, including GDB (which you for some
reason seem to reject completely AFAU) and even printf-debugging
usually do the job for me.  So the current situation being described
in such apocalyptic terms is not something I can agree with.

> One of these things is having meaningless anonymous entries in
> backtraces and C-h v, with no connection back to the source code.
> feature/named-lambdas fixes this.

Won't jumping to the exact source line where the error happened fix
this better?  If I have a single significant gripe against Emacs Lisp
backtraces, it is that there's no way of jumping to the offending
source line in each stack frame, something that is very natural to
provide.  Anonymous lambdas come as a very distant second or third
problem, at least IME.