bug#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.)

[Alan Mackenzie <acm@muc.de>]

Hello again, Stefan.

On Sun, Mar 10, 2024 at 13:19:03 -0400, Stefan Monnier wrote:

[ .... ]

> >> - My gut tells me that changing backquote can't be right.

> > I tend to agree.  I put the code into backquote-process when having
> > problems with things like:

> >        (mapatoms #'(lambda (,(car spec)) ,@body)

[ .... ]

> >>   (lambda (f) ..) *can* appear within a backquote without it being an
> >>   actual lambda expression.
> >>   What alternatives have you considered?
> > Not a lot of them, as yet.  Maybe testing for (function (lambda ...))
> > would be safer.

> No matter how many extra tests you add to reduce the frequency, you're
> fundamentally adding a bug :-(

Well, macroexp--expand-all has treated (function (lambda ...)) as a
function long before I started on this project in November.  Would
trusting the same thing in backquote-process be any more dangerous?

Anyway, I've started looking at getting that extra code out of
backquote.el.  Simply commenting it out produces build time errors, which
shows that it's not totally redundant.

How about adding (an) extra arm(s) to the large pcase in
macroexp--expand-all which would recognise backquote's output for
"evaluated" lambdas.

What we get back from backquote looks like:

(cons 'lambda (cons plain-args body)) or
(list 'lambda args)) or maybe one or two other forms.

So I could extend such code fragments to add posification code quite
easily.  I'm not sure it'd be more elegant than what's currently in
backquote.el, though.  I think I'll give it a try.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).