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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Thu, Nov 02, 2023 at 12:09:28 +0200, Eli Zaretskii wrote:
> > 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.

Implementing the "simpler" version which blocks extensions would be
wasted effort if we decide we want those extensions.  In practice, what
is likely to happen is that the extensions would never be implemented.
Surely these are central questions which should be answered before
embarking on a restricted implementation.  (OK, I can see the irony
here.)

> > > 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.

Perhaps a less heated comparison of feature/named-lambdas's advantages
with its disadvantages would be beneficial, here.

> > 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.

Really?  Would you be happier if this code didn't work, or didn't exist?

> > > 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.

What would we be sacrificing if we were to merge this feature?

> > 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.

One of the issues that Stefan raised was that the defining symbol in
"thousands" of closures resulting from a single command would be an
unacceptable "waste" of storage.  I don't think this would be the case.
This is something capable of measurement, something I would expect Stefan
to do to back up his case.

> > > 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.

Such ideas haven't been forthcoming in the last day or two.

> > 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
> of compromise, even if you keep your opinions.

I don't think Stefan is talking about a compromise.  He's talking about
discarding my changes entirely, and starting again from scratch, working
to design principles and with design goals I disagree with.  How is that
a compromise?

Or had you in mind something less drastic?

> > 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.

I use gdb, not as fluently as you do, but I use it.  But debugging Lisp
with gdb doesn't seem natural and isn't easy.  And yes, I've put printf
(literally printf) into C code quite a bit, too.

A couple of days ago I got the error message:

    emacs-lisp/eieio.el:55:2: Error: Wrong type argument: listp, :autoload-end

At the indicated file position there was just a `require' form.  So there
was no information about where the error happened, what detected the
error, or what function or what variable gave or had the value
:autoload-end.  It says little more than "there was an error".  This is
what I mean by "horrible".

In this case I was able to sort it out relatively quickly from examining
my recent changes, but that's not always the case.  This is typical of
the quality of error messages which Emacs produces, in my experience.
I'd like to improve this.

> > 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?

It would be a different solution to a slightly different problem.  Just
seeing a file name and location is less informative than seeing the
defining symbol, and forces the user to take action to get more
information.  But I'm looking at putting this facility into the code too,
after comments from Mattias (in July) and Stefan.

> 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.

This would be more difficult to implement.  We currently have in Emacs no 
connection between our execution point and our source code, beyond the
symbols with position used in compilation.

> Anonymous lambdas come as a very distant second or third problem, at
> least IME.

They've been a problem for me, at least.  That's why I set about solving
it.  And being of a lower priority is no reason to reject an existing
fix.

-- 
Alan Mackenzie (Nuremberg, Germany).