New branch feature/named-lambdas.

New branch feature/named-lambdas.

[Alan Mackenzie]

Hello, Emacs.

I've just committed the first version of branch feature/named-lambdas.

This will output the @dfn{defining symbol} of any anonymous functions in
backtraces.

For example, in

    (defun foo ()
      "foo doc string"
      (lambda (bar) "lambda doc string" (car bar)))

M-: (funcall (foo) 'baz) will produce this backtrace:

Debugger entered--Lisp error: (wrong-type-argument listp baz)
  car(baz)
  {foo} #f(compiled-function (bar) "lambda doc string" #<bytecode -0x105933d3d8452e4e>)(baz)  <=============================
  funcall({foo} #f(compiled-function (bar) "lambda doc string" #<bytecode -0x105933d3d8452e4e>) baz)
  (progn (funcall (foo) 'baz))
  elisp--eval-last-sexp(nil)
  eval-last-sexp(nil)
  funcall-interactively(eval-last-sexp nil)
  command-execute(eval-last-sexp)

..  Note the {foo} on the third and fourth lines.  This is (usually) the
defun where the lambda was defined, and is helpful in locating its
source code.

This was achieved by adding an extra defining-symbol field to each of
the three forms of function (interpreted, byte-compiled,
native-compiled).  It is indended that this version of Emacs will
continue to handle functions compiled without this enhancement.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: New branch feature/named-lambdas.

[Philip Kaludercic]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Emacs.
>
> I've just committed the first version of branch feature/named-lambdas.
>
> This will output the @dfn{defining symbol} of any anonymous functions in
> backtraces.
>
> For example, in
>
>     (defun foo ()
>       "foo doc string"
>       (lambda (bar) "lambda doc string" (car bar)))
>
> M-: (funcall (foo) 'baz) will produce this backtrace:
>
> Debugger entered--Lisp error: (wrong-type-argument listp baz)
>   car(baz)
>   {foo} #f(compiled-function (bar) "lambda doc string" #<bytecode -0x105933d3d8452e4e>)(baz)  <=============================
>   funcall({foo} #f(compiled-function (bar) "lambda doc string" #<bytecode -0x105933d3d8452e4e>) baz)
>   (progn (funcall (foo) 'baz))
>   elisp--eval-last-sexp(nil)
>   eval-last-sexp(nil)
>   funcall-interactively(eval-last-sexp nil)
>   command-execute(eval-last-sexp)
>
> ..  Note the {foo} on the third and fourth lines.  This is (usually) the
> defun where the lambda was defined, and is helpful in locating its
> source code.
>
> This was achieved by adding an extra defining-symbol field to each of
> the three forms of function (interpreted, byte-compiled,
> native-compiled).  It is indended that this version of Emacs will
> continue to handle functions compiled without this enhancement.

I think the idea is nice, but there are a lot of whitespace changes in
your commit that make identifying the real changes a bit difficult.

Re: New branch feature/named-lambdas.

[Alan Mackenzie]

Hello, Philip.

On Mon, Jul 17, 2023 at 19:52:01 +0000, Philip Kaludercic wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > Hello, Emacs.

> > I've just committed the first version of branch feature/named-lambdas.

> > This will output the @dfn{defining symbol} of any anonymous functions in
> > backtraces.

> > For example, in

> >     (defun foo ()
> >       "foo doc string"
> >       (lambda (bar) "lambda doc string" (car bar)))

> > M-: (funcall (foo) 'baz) will produce this backtrace:

> > Debugger entered--Lisp error: (wrong-type-argument listp baz)
> >   car(baz)
> >   {foo} #f(compiled-function (bar) "lambda doc string" #<bytecode -0x105933d3d8452e4e>)(baz)  <=============================
> >   funcall({foo} #f(compiled-function (bar) "lambda doc string" #<bytecode -0x105933d3d8452e4e>) baz)
> >   (progn (funcall (foo) 'baz))
> >   elisp--eval-last-sexp(nil)
> >   eval-last-sexp(nil)
> >   funcall-interactively(eval-last-sexp nil)
> >   command-execute(eval-last-sexp)

> > ..  Note the {foo} on the third and fourth lines.  This is (usually) the
> > defun where the lambda was defined, and is helpful in locating its
> > source code.

> > This was achieved by adding an extra defining-symbol field to each of
> > the three forms of function (interpreted, byte-compiled,
> > native-compiled).  It is indended that this version of Emacs will
> > continue to handle functions compiled without this enhancement.

> I think the idea is nice, but there are a lot of whitespace changes in
> your commit that make identifying the real changes a bit difficult.

Yes.  I was instinctively correcting WS mis-alignment as I went along.
This was a mistake, sorry.

I've found a way to identify where these WS changes are, involving a git
diff, and a git diff -b, taking the diff -u between these two outputs,
then feeding that to grep '^[+-]@@'.  This identifies 10 places where the
whitespace has changed.  I hope that's all of them, but I'll check.

I'll go through these tomorrow morning and commit them to
feature/named-lambdas.  This will have the advantage of making my patch
file several hundred lines shorter.  ;-)

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: New branch feature/named-lambdas.

[Alan Mackenzie]

Hello, Philip.

On Mon, Jul 17, 2023 at 21:37:41 +0000, Alan Mackenzie wrote:
> On Mon, Jul 17, 2023 at 19:52:01 +0000, Philip Kaludercic wrote:
> > Alan Mackenzie <acm@muc.de> writes:

[ .... ]

> > > This was achieved by adding an extra defining-symbol field to each of
> > > the three forms of function (interpreted, byte-compiled,
> > > native-compiled).  It is indended that this version of Emacs will
> > > continue to handle functions compiled without this enhancement.

> > I think the idea is nice, but there are a lot of whitespace changes in
> > your commit that make identifying the real changes a bit difficult.

> Yes.  I was instinctively correcting WS mis-alignment as I went along.
> This was a mistake, sorry.

> I've found a way to identify where these WS changes are, involving a git
> diff, and a git diff -b, taking the diff -u between these two outputs,
> then feeding that to grep '^[+-]@@'.  This identifies 10 places where the
> whitespace has changed.  I hope that's all of them, but I'll check.

> I'll go through these tomorrow morning and commit them to
> feature/named-lambdas.  This will have the advantage of making my patch
> file several hundred lines shorter.  ;-)

I've reverted a few whitespace changes (together with an unintentional
deletion of a condition-case in comp.el).

Most of the the WS changes were actually due to semantic changes, e.g. by
enclosing a block of forms in an extra (let ....).

It can help to use the -b flag in git diff (or indeed in diff itself),
e.g.

    git diff -b master..feature/named-lambdas

..

> -- 
> Alan Mackenzie (Nuremberg, Germany).

Re: New branch feature/named-lambdas.

[Ihor Radchenko]

Alan Mackenzie <acm@muc.de> writes:

> Debugger entered--Lisp error: (wrong-type-argument listp baz)
>   car(baz)
>   {foo} #f(compiled-function (bar) "lambda doc string" #<bytecode -0x105933d3d8452e4e>)(baz)

One slightly annoying thing here is that argument values are listed all
the way at the end, after the long unreadable <...bytecode...> part.

Would it make sense to have {foo(baz)} #f... instead?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>