bug#69470: bug in cl-return-from

bug#69470: bug in cl-return-from

[Robert Boyer]

[-- Attachment #1: Type: text/plain, Size: 5145 bytes --]

It is almost certainly a bug in the definition of cl-return-from that the
following
does not work.  I have no idea whether it is possible to fix.  Could be
really hard
or undesirable to fix.  I know nothing.

Emacs is great beyond words.

Thanks so much,

Bob

  (defun foo () (cl-return-from foo 3))
  (foo)

I strongly believe that in Common Lisp, every (defun foo ...) wraps
a block named foo around the ...


From: bob <bob@penguin>
To: bug-gnu-emacs@gnu.org
Subject: 28.2; cl-return-from not right
--text follows this line--




In GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.37,
cairo version 1.16.0)
 of 2023-05-13, modified by Debian built on x86-ubc-01
Windowing system distributor 'The X.Org Foundation', version 11.0.12014000
System Description: Debian GNU/Linux 12 (bookworm)

Configured using:
 'configure --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/libexec
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-libsystemd --with-pop=yes
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/28.2/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/28.2/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-mailutils
 --with-native-compilation --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/libexec
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-libsystemd --with-pop=yes
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/28.2/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/28.2/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-mailutils
 --with-native-compilation --with-cairo --with-x=yes
 --with-x-toolkit=gtk3 --with-toolkit-scroll-bars 'CFLAGS=-g -O2
 -ffile-prefix-map=/build/emacs-mPr7Vr/emacs-28.2+1=.
 -fstack-protector-strong -Wformat -Werror=format-security -Wall'
 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' LDFLAGS=-Wl,-z,relro'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF
TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM GTK3 ZLIB

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

Major mode: Shell

Minor modes in effect:
  shell-dirtrack-mode: t
  display-time-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-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 puny rfc822 mml mml-sec epa
derived epg rfc6068 epg-config gnus-util mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail misearch
multi-isearch help-fns radix-tree cl-print debug backtrace find-func
compile text-property-search comp comp-cstr warnings rx cl-extra
help-mode time-date cus-start etags fileloop generator xref project
dired-aux cus-edit pp cus-load wid-edit trace sh-script smie executable
dired dired-loaddefs cal-menu calendar cal-loaddefs ange-ftp shell
pcomplete comint ansi-color ring benchmark time rmail rmail-loaddefs
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils face-remap
finder-inf package browse-url url url-proxy url-privacy url-expand
url-methods url-history url-cookie url-domsuf url-util mailcap
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json subr-x map url-vars seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib iso-transl tooltip eldoc
paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode
mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-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 emoji-zwj 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 dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 168468 8306)
 (symbols 48 13596 1)
 (strings 32 42207 4014)
 (string-bytes 1 1386221)
 (vectors 16 26817)
 (vector-slots 8 482737 48574)
 (floats 8 59 280)
 (intervals 56 1830 91)
 (buffers 992 32))

[-- Attachment #2: Type: text/html, Size: 5735 bytes --]

bug#69470: bug in cl-return-from

[Andrea Corallo]

Robert Boyer <robertstephenboyer@gmail.com> writes:

> It is almost certainly a bug in the definition of cl-return-from that the following
> does not work.  I have no idea whether it is possible to fix.  Could be really hard
> or undesirable to fix.  I know nothing.
>
> Emacs is great beyond words.
>
> Thanks so much,
>
> Bob
>
>   (defun foo () (cl-return-from foo 3))
>   (foo)
>
> I strongly believe that in Common Lisp, every (defun foo ...) wraps
> a block named foo around the ...

Hi Bob,

unfortunately or not, this is elisp not CL :)

If you want to do that the following works:

(cl-defun foo () (cl-return-from foo 3))
(foo) => 3

Best Regards

  Andrea

bug#69470: bug in cl-return-from

[Robert Boyer]

[-- Attachment #1: Type: text/plain, Size: 883 bytes --]

Got it.  Thank you so very much.

Bob


On Thu, Feb 29, 2024 at 10:59 AM Andrea Corallo <acorallo@gnu.org> wrote:

> Robert Boyer <robertstephenboyer@gmail.com> writes:
>
> > It is almost certainly a bug in the definition of cl-return-from that
> the following
> > does not work.  I have no idea whether it is possible to fix.  Could be
> really hard
> > or undesirable to fix.  I know nothing.
> >
> > Emacs is great beyond words.
> >
> > Thanks so much,
> >
> > Bob
> >
> >   (defun foo () (cl-return-from foo 3))
> >   (foo)
> >
> > I strongly believe that in Common Lisp, every (defun foo ...) wraps
> > a block named foo around the ...
>
> Hi Bob,
>
> unfortunately or not, this is elisp not CL :)
>
> If you want to do that the following works:
>
> (cl-defun foo () (cl-return-from foo 3))
> (foo) => 3
>
> Best Regards
>
>   Andrea
>

[-- Attachment #2: Type: text/html, Size: 1377 bytes --]

bug#69470: bug in cl-return-from

[Eli Zaretskii]

> Cc: 69470@debbugs.gnu.org
> From: Robert Boyer <robertstephenboyer@gmail.com>
> Date: Thu, 29 Feb 2024 11:06:18 -0600
> 
> Got it.  Thank you so very much.

I'm therefore closing this bug.

bug#69470: bug in cl-return-from

[Robert Boyer]

[-- Attachment #1: Type: text/plain, Size: 559 bytes --]

I do not think that it is reasonable to say that it is ok to close that bug
report unless you
can not only find that file, literally, for which I sent you a url , so
that you can fetch it, but
also tell me that you can move to its bottom after finding it.

Bob



On Sat, Mar 2, 2024 at 1:48 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > Cc: 69470@debbugs.gnu.org
> > From: Robert Boyer <robertstephenboyer@gmail.com>
> > Date: Thu, 29 Feb 2024 11:06:18 -0600
> >
> > Got it.  Thank you so very much.
>
> I'm therefore closing this bug.
>

[-- Attachment #2: Type: text/html, Size: 1055 bytes --]

bug#69470: bug in cl-return-from

[Eli Zaretskii]

> From: Robert Boyer <robertstephenboyer@gmail.com>
> Date: Sat, 2 Mar 2024 02:59:12 -0600
> Cc: acorallo@gnu.org, 69470-done@debbugs.gnu.org
> 
> I do not think that it is reasonable to say that it is ok to close that bug report unless you
> can not only find that file, literally, for which I sent you a url , so that you can fetch it, but
> also tell me that you can move to its bottom after finding it.

You are confused: this bug is not about the 1GB file, it's about a
different issue.  See the Subject line.

bug#69470: bug in cl-return-from

[Robert Boyer]

[-- Attachment #1: Type: text/plain, Size: 708 bytes --]

You are 100% right.  I was indeed confused.  My most sincere apologies.

Bob


On Sat, Mar 2, 2024 at 5:11 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Robert Boyer <robertstephenboyer@gmail.com>
> > Date: Sat, 2 Mar 2024 02:59:12 -0600
> > Cc: acorallo@gnu.org, 69470-done@debbugs.gnu.org
> >
> > I do not think that it is reasonable to say that it is ok to close that
> bug report unless you
> > can not only find that file, literally, for which I sent you a url , so
> that you can fetch it, but
> > also tell me that you can move to its bottom after finding it.
>
> You are confused: this bug is not about the 1GB file, it's about a
> different issue.  See the Subject line.
>

[-- Attachment #2: Type: text/html, Size: 1242 bytes --]