unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Thuna <thuna.cing@gmail.com>
To: 72279@debbugs.gnu.org
Cc: Stefan Monnier <monnier@iro.umontreal.ca>
Subject: bug#72279: [PATCH] Non-local exits from outside the lexical scope are caught by cl-block
Date: Fri, 26 Jul 2024 02:41:59 +0200	[thread overview]
Message-ID: <87cyn13rxk.fsf@gmail.com> (raw)
In-Reply-To: <87wmla4rqq.fsf@gmail.com>


> BTW, for the second patch a simpler solution is to expand
>
>     (cl-block A FOO)
> to
>     (let ((cl--block--A ',(make-symbol "A")))
>       (catch cl--block--A FOO))
>
> and
>
>     (cl-return B FOO)
> to
>     (throw cl--block--B FOO)
>
> which will signal an "unknown variable cl--block--B" if a `cl-return` is
> used outside of its block.

Aha, yes, that would indeed be simpler.

> But the optimization of `cl-block` when the tag is not used is
> important, so I don't think it's a good approach.

I don't have any particular complaints against keeping this
optimization, but for the record would you be able to expand on what
exactly the problem is?  It doesn't seem obvious to me that unused
`catch'es would make such a meaningful difference.

> Yup, as I said, the "optimization" is important (most of the
> `cl-block`s are implicit and unused, IME).

It would be nice if this would be documented at least in a comment above
`cl-block', even though it's unlikely that it will see too many changes.

>> I see two possible solutions, either define a (setf catch) or switch
>> to defsubst instead of cl-defsubst.
>
> I don't think we can implement a `setf catch` (tho we could probably
> come up with a hack which works in practice for those
> cl-defstruct slots).  🙁
>
> IIRC for the slot accessors `defsubst` would lead to worse code than
> what we currently get with `cl-defsubst` so it wouldn't be as good, but
> I believe we could use `define-inline` instead.

That sounds like a solution.  Defining a hack for `setf catch' seems
like it would lead to a lot of problems down the line, so it would be
better to put it off until someone comes up with a good way to do it
(though I doubt it is possible given dynamic exits).






  reply	other threads:[~2024-07-26  0:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-24 17:36 bug#72279: [PATCH] Non-local exits from outside the lexical scope are caught by cl-block Thuna
2024-07-25 15:15 ` Andrea Corallo
2024-07-25 17:00   ` Thuna
2024-07-25 17:22   ` bug#72279: FSF copyright assignment Thuna
2024-07-25 23:24 ` bug#72279: [PATCH] Non-local exits from outside the lexical scope are caught by cl-block Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-26  0:41   ` Thuna [this message]
2024-07-26  7:39     ` Andrea Corallo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87cyn13rxk.fsf@gmail.com \
    --to=thuna.cing@gmail.com \
    --cc=72279@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).