bug#48585: 28.0.50; Missing Edebug instrumentation for some 'if-let' variants

bug#48585: 28.0.50; Missing Edebug instrumentation for some 'if-let' variants

[Philipp]

Instrument the following definition using C-u C-M-x:
(defun f (x) (if-let* (x) 1))

Then, evaluate this form:
(f 2)

Edebug will step into 'f', but won't stop at 'x'.

The problem lies in this part of the Edebug specification for 'if-let*':

[&or symbolp (symbolp form) (form)]

The 'symbolp' specification element causes Edebug to not instrument the
'x' symbol.  However, the 'symbolp' specification is also necessary
here; we couldn't just replace it with 'form' because that would make
the branches overlap.  What we'd need here is something like
[&and symbolp form], i.e. match only in case of a symbol, but also
instrument as a form.  IIUC Edebug doesn't support such constructs yet.


In GNU Emacs 28.0.50 (build 125, aarch64-apple-darwin20.4.0, NS appkit-2022.44 Version 11.3.1 (Build 20E241))
 of 2021-05-22
Repository revision: 91fa95bde0619b4f3bc7d93d06c7c75998b1588d
Repository branch: master
Windowing system distributor 'Apple', version 10.3.2022
System Description:  macOS 11.3.1

Configured using:
 'configure --with-modules --without-xml2 --without-pop --with-mailutils
 --enable-gcc-warnings=warn-only --enable-checking=all
 --enable-check-lisp-object-type 'CFLAGS=-ggdb3 -O0''

Configured features:
ACL GNUTLS JSON LCMS2 MODULES NOTIFY KQUEUE NS PDUMPER PNG THREADS
TOOLKIT_SCROLL_BARS ZLIB

Important settings:
  value of $LANG: de_DE.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc dired dired-loaddefs rfc822
mml mml-sec epa epg epg-config gnus-util rmail rmail-loaddefs time-date
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils phst skeleton derived edmacro kmacro pcase ffap thingatpt url
url-proxy url-privacy url-expand url-methods url-history url-cookie
url-domsuf url-util url-parse auth-source cl-seq eieio eieio-core
cl-macs eieio-loaddefs password-cache json map url-vars mailcap rx
gnutls puny dbus xml subr-x seq byte-opt gv bytecomp byte-compile cconv
compile text-property-search comint ansi-color ring cl-loaddefs cl-lib
iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/ns-win ns-win ucs-normalize mule-util
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads kqueue cocoa ns lcms2
multi-tty make-network-process emacs)

Memory information:
((conses 16 70783 6422)
 (symbols 48 8363 1)
 (strings 32 24254 2096)
 (string-bytes 1 793113)
 (vectors 16 16076)
 (vector-slots 8 212949 7797)
 (floats 8 26 28)
 (intervals 56 219 0)
 (buffers 992 10))

bug#48585: 28.0.50; Missing Edebug instrumentation for some 'if-let' variants

[Lars Ingebrigtsen]

Philipp <p.stephani2@gmail.com> writes:

> Instrument the following definition using C-u C-M-x:
> (defun f (x) (if-let* (x) 1))
>
> Then, evaluate this form:
> (f 2)
>
> Edebug will step into 'f', but won't stop at 'x'.
>
> The problem lies in this part of the Edebug specification for 'if-let*':
>
> [&or symbolp (symbolp form) (form)]
>
> The 'symbolp' specification element causes Edebug to not instrument the
> 'x' symbol.  However, the 'symbolp' specification is also necessary
> here; we couldn't just replace it with 'form' because that would make
> the branches overlap.  What we'd need here is something like
> [&and symbolp form], i.e. match only in case of a symbol, but also
> instrument as a form.  IIUC Edebug doesn't support such constructs yet.

Perhaps Stefan has some comments here; added to the CCs.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#48585: 28.0.50; Missing Edebug instrumentation for some 'if-let' variants

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> The 'symbolp' specification element causes Edebug to not instrument the
>> 'x' symbol.  However, the 'symbolp' specification is also necessary
>> here; we couldn't just replace it with 'form' because that would make
>> the branches overlap.  What we'd need here is something like
>> [&and symbolp form], i.e. match only in case of a symbol, but also
>> instrument as a form.  IIUC Edebug doesn't support such constructs yet.
>
> Perhaps Stefan has some comments here; added to the CCs.

The instrumentation takes place before expanding the macro, so either we
instrument the `x` into a form (edebug-<foo> ... x ...) or we leave the
`x` untouched and have no instrumentation.  We can't have it both ways
from that side.

So if we want the occurrence of `x` which *evaluates* `x` (as opposed to
the occurrence that *binds* the new variable) to be instrumented, we
need to change the macro to accept a "variable name" of the form
(edebug-<foo> ... x ...) and somehow strip the edebug instrumentation
when we use the argument as a variable name in a binding position.

As someone who doesn't much like `if-let`, I'll let someone else figure
out how to that somewhat cleanly.  Also to be honest I also wonder if
that would be worthwhile.


        Stefan

bug#48585: 28.0.50; Missing Edebug instrumentation for some 'if-let' variants

[Michael Heerdegen]

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

> As someone who doesn't much like `if-let`, I'll let someone else figure
> out how to that somewhat cleanly.  Also to be honest I also wonder if
> that would be worthwhile.

It's easy to get rid of the `x` occurrence that *binds* (in the
expansion) by changing `internal--build-binding' - the name of the
binding symbol doesn't matter in this case.

Then I guess we could use this `&interpose' Edebug spec but it's
undocumented and not really trivial to understand.  But looks like the
right tool for this case... (?)

Michael.

bug#48585: 28.0.50; Missing Edebug instrumentation for some 'if-let' variants

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Then I guess we could use this `&interpose' Edebug spec but it's
> undocumented and not really trivial to understand.

But seems the return value is an Edebug spec again.  This would not help
in this case then.

Michael.

bug#48585: 28.0.50; Missing Edebug instrumentation for some 'if-let' variants

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Michael Heerdegen [2022-07-17 03:36:33] wrote:
> Michael Heerdegen <michael_heerdegen@web.de> writes:
>> Then I guess we could use this `&interpose' Edebug spec but it's
>> undocumented and not really trivial to understand.
> But seems the return value is an Edebug spec again.  This would not help
> in this case then.

No, the problem can't be fixed in the edebug-spec.  Either we live with
the current behavior (perfectly acceptable if you ask me), or you need
to change the definition of the macro so it explicitly strips the Edebug
instrumentation (if present) at those places where it's not desired.


        Stefan

bug#48585: 28.0.50; Missing Edebug instrumentation for some 'if-let' variants

[Michael Heerdegen]

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

> [...] or you need to change the definition of the macro so it
> explicitly strips the Edebug instrumentation (if present) at those
> places where it's not desired.

That would be ugly.  I agree it's then acceptable to live with the
current behavior.

Michael.

bug#48585: 28.0.50; Missing Edebug instrumentation for some 'if-let' variants

[Michael Heerdegen]

Philipp <p.stephani2@gmail.com> writes:

> Instrument the following definition using C-u C-M-x:
> (defun f (x) (if-let* (x) 1))
>
> Then, evaluate this form:
> (f 2)
>
> Edebug will step into 'f', but won't stop at 'x'.
>
> The problem lies in this part of the Edebug specification for 'if-let*':
>
> [&or symbolp (symbolp form) (form)]
>
> The 'symbolp' specification element causes Edebug to not instrument the
> 'x' symbol.  However, the 'symbolp' specification is also necessary
> here; we couldn't just replace it with 'form' because that would make
> the branches overlap.

Dunno how bad an overlap is.  I tried this:

(debug ((&rest [&or (symbolp form) (form) form])
                   body))

That lets instrumenting error:

| internal-macroexpand-for-load: Eager macro-expansion failure: (error
| "`let' bindings can have only one value-form" edebug-after 0 1 x)

Does that happen because `x` appears as binding _variable_ in the
expansion, and Ebebug messes with that?  Then we would have a second
problem.

Michael.