GNU bug report logs - #47677
[PATCH] condition-case success continuation

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 47677 in the body.
You can then email your comments to 47677 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] condition-case success continuation
Date: Fri, 9 Apr 2021 22:26:49 +0200

[Message part 1 (text/plain, inline)]

This patch adds the condition-case handler syntax

  (:success BODY)

for code executed when the protected form terminates without error. BODY is then executed with the variable bound to the result of the protected form, and the result of BODY is then the value of the condition-case form as usual.

This plugs an annoying hole in elisp: there hasn't been any direct access to the success continuation which forced programmers to resort to various hacks such as tagging the returned value and then immediately testing that tag, as in

(let ((input (condition-case _
                 (cons 'ok (read buffer))
               (end-of-file 'eof))))
  (when (consp input)
    (use (cdr input))))

Now we can write

(condition-case result
    (read buffer)
  (end-of-file 'eof)
  (:success (use result)))

which is more concise, elegant and performant.

Like all condition-case handlers (but in contrast to the protected form), the success handler is in the tail position and the limited self-tail-recursion of cl-labels (and named-let) works there as expected.

Details of the syntax can be changed if there is a very good reason for it. Many other languages have more or less independently added equivalent constructs. Common Lisp's `handler-case` has a very similar feature (:no-error).

It would be nice to give `catch` the same treatment. A particularly flexible solution would be to add `catch` handlers to `condition-case`, which would then be able to handle everything. Unless there is a strong reason for doing it right away, it can be seen as a later improvement.

[0001-Add-condition-case-success-handler.patch (application/octet-stream, attachment)]

Message #8 received at 47677 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 47677 <at> debbugs.gnu.org
Subject: Re: bug#47677: [PATCH] condition-case success continuation
Date: Sat, 10 Apr 2021 19:52:19 -0400

> This patch adds the condition-case handler syntax
>
>   (:success BODY)

In the tests, you might want to add one with a lambda expression which
captures a mutated success variable, as in

    (apply (condition-case res
               42
             (:success (prog1 (list (lambda (x) (+ res x)) res)
                         (setq res 0)))))

since this requires special handling in cconv.el.
Other than that, the patch looks good to me.

> Details of the syntax can be changed if there is a very good reason
> for it. Many other languages have more or less independently added
> equivalent constructs. Common Lisp's `handler-case` has a very similar
> feature (:no-error).

Any particular reason you chose ;success instead of :no-error?

> It would be nice to give `catch` the same treatment. A particularly
> flexible solution would be to add `catch` handlers to
> `condition-case`, which would then be able to handle
> everything. Unless there is a strong reason for doing it right away,
> it can be seen as a later improvement.

Let's take it one step at a time.


        Stefan

Message #11 received at 47677 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 47677 <at> debbugs.gnu.org
Subject: Re: bug#47677: [PATCH] condition-case success continuation
Date: Sun, 11 Apr 2021 13:13:37 +0200

[Message part 1 (text/plain, inline)]

11 apr. 2021 kl. 01.52 skrev Stefan Monnier <monnier <at> iro.umontreal.ca>:

> In the tests, you might want to add one with a lambda expression which
> captures a mutated success variable, as in
> 
>    (apply (condition-case res
>               42
>             (:success (prog1 (list (lambda (x) (+ res x)) res)
>                         (setq res 0)))))
> 
> since this requires special handling in cconv.el.

Good catch! Fixed on master. (And I've added more test cases to the patch.)

> Any particular reason you chose ;success instead of :no-error?

Only a few weak reasons -- some conditions (like quit) aren't errors, although the documentation is very inconsistent on that point. And :success felt slightly more descriptive, and it doesn't have a negation in the name.

Names like :default, :else, :otherwise etc were rejected because they could be interpreted as 'any other error'.

It may be a bit too far over the moon though. Would :not-a-complete-failure be better? Fits my gloomy national temperaments (all of them) better.

Still undecided!

[0001-Add-condition-case-success-handler-bug-47677.patch (application/octet-stream, attachment)]

Message #14 received at 47677 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 47677 <at> debbugs.gnu.org
Subject: Re: bug#47677: [PATCH] condition-case success continuation
Date: Mon, 12 Apr 2021 10:49:11 +0200

Mattias Engdegård <mattiase <at> acm.org> writes:

> It may be a bit too far over the moon though. Would
> :not-a-complete-failure be better? Fits my gloomy national
> temperaments (all of them) better.

:-)

I like :success here.  Let's bring some positivity.  And I also like
the feature -- you sometimes see people doing

(condition-case
  (progn
    (something-that-may-fail)
    (setq didnt-fail t))
  (error ...))
(when didnt-fail
  ...)

and this would be much nicer.

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

Message #17 received at 47677 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Mattias Engdegård <mattiase <at> acm.org>,
 47677 <at> debbugs.gnu.org
Subject: Re: bug#47677: [PATCH] condition-case success continuation
Date: Mon, 12 Apr 2021 11:10:40 -0400

>> It may be a bit too far over the moon though. Would
>> :not-a-complete-failure be better? Fits my gloomy national
>> temperaments (all of them) better.
>
> :-)
>
> I like :success here.  Let's bring some positivity.  And I also like
> the feature -- you sometimes see people doing
>
> (condition-case
>   (progn
>     (something-that-may-fail)
>     (setq didnt-fail t))
>   (error ...))
> (when didnt-fail
>   ...)
>
> and this would be much nicer.

Indeed, a nice sidekick to Mattias's patch would be another patch which
rewrites some of those condition-cases.  I know I wrote some of those
but somehow can't remember where, nor can I think of a good way to grep
for them.


        Stefan

Message #20 received at 47677 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 47677 <at> debbugs.gnu.org
Subject: Re: bug#47677: [PATCH] condition-case success continuation
Date: Mon, 12 Apr 2021 21:20:24 +0200

[Message part 1 (text/plain, inline)]

Here is an updated patch that reduces some code duplication in the compiler and fixes an embarrassing bug, and as a bonus, an experimental add-on that allows catching throws in condition-case using the handler syntax

  ((:catch TAG) BODY...)

Unfortunately but unsurprisingly the decision to evaluate the TAG expressions made everything much messier than anticipated. It does work, though, and if you would like to redefine `catch` as the macro

(defmacro catch (tag &rest body)
  (let ((var (gensym)))
    `(condition-case ,var (progn ,@body) ((:catch ,tag) ,var))))

then that will work, too (with minor byte-code inefficiency that could easily be addressed).
Any combination of error, :catch and :success handlers is permitted, making this a very versatile construct.

It may be a good idea to do away with the TAG evaluation since that flexibility isn't likely to be in high demand.

[0001-Add-condition-case-success-handler-bug-47677.patch (application/octet-stream, attachment)]

[catch-in-condition-case.diff (application/octet-stream, attachment)]

[Message part 4 (text/plain, inline)]

Message #23 received at 47677 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 47677 <at> debbugs.gnu.org
Subject: Re: bug#47677: [PATCH] condition-case success continuation
Date: Tue, 13 Apr 2021 09:38:10 +0200

Mattias Engdegård <mattiase <at> acm.org> writes:

> Here is an updated patch that reduces some code duplication in the
> compiler and fixes an embarrassing bug, and as a bonus, an
> experimental add-on that allows catching throws in condition-case
> using the handler syntax
>
>   ((:catch TAG) BODY...)

I'm not quite sure I understand the use case for this -- we already have
a general catch/throw infrastructure, so this sounds like a somewhat odd
addition.

That is, currently you know what to look for when reading code that does
a throw, and this introduces a second thing to look for, and I'm not
sure that's a net win.

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

Message #26 received at 47677 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 47677 <at> debbugs.gnu.org
Subject: Re: bug#47677: [PATCH] condition-case success continuation
Date: Tue, 13 Apr 2021 10:52:54 +0200

13 apr. 2021 kl. 09.38 skrev Lars Ingebrigtsen <larsi <at> gnus.org>:

>>  ((:catch TAG) BODY...)
> 
> I'm not quite sure I understand the use case for this -- we already have
> a general catch/throw infrastructure, so this sounds like a somewhat odd
> addition.

Oh, it was just proof-of-concept code to show that such a generalisation would be possible should it be desired later. It's not part of the immediate proposal. Sorry about the confusion.

Our present `catch` has the same flaw as `condition-case` in that it does not give access to the success continuation, leading to hacks similar to the one you mentioned. We could extend `catch` instead, maybe like this:

  (catch TAG :in BODY-FORM :success VAR SUCCESS-FORM)

but what if you want to catch multiple tags, or both throws and errors? The constructs don't compose; nesting them hides the success continuation of the inner forms.

Message #29 received at 47677 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 47677 <at> debbugs.gnu.org
Subject: Re: bug#47677: [PATCH] condition-case success continuation
Date: Wed, 14 Apr 2021 11:29:21 +0200

Mattias Engdegård <mattiase <at> acm.org> writes:

> Oh, it was just proof-of-concept code to show that such a
> generalisation would be possible should it be desired later. It's not
> part of the immediate proposal. Sorry about the confusion.

Oh, OK.  :-)

> Our present `catch` has the same flaw as `condition-case` in that it
> does not give access to the success continuation, leading to hacks
> similar to the one you mentioned.

Yes, that's true.

> We could extend `catch` instead, maybe like this:
>
>   (catch TAG :in BODY-FORM :success VAR SUCCESS-FORM)
>
> but what if you want to catch multiple tags, or both throws and
> errors? The constructs don't compose; nesting them hides the success
> continuation of the inner forms.

Yeah, I think extending `catch' here would be less than optimal, but I
don't really have any suggestions here -- I use `throw/catch' so little
that I have no gut feeling about what I see as being useful.

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

Message #32 received at 47677 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 47677 <at> debbugs.gnu.org
Subject: Re: bug#47677: [PATCH] condition-case success continuation
Date: Thu, 15 Apr 2021 15:54:27 +0200

14 apr. 2021 kl. 11.29 skrev Lars Ingebrigtsen <larsi <at> gnus.org>:

> Yeah, I think extending `catch' here would be less than optimal, but I
> don't really have any suggestions here -- I use `throw/catch' so little
> that I have no gut feeling about what I see as being useful.

It's unfortunate that elisp has two incompatible variants, throw/catch and signal/condition-case, of essentially the same control structure. In practice throw/catch tends to be used more for non-error situations, but that's just a matter of style -- the underlying mechanisms are basically the same.

In any case the patch apparently wasn't bad enough to be rejected outright so it's boldly been pushed to master. If the general opinion is that :no-error (or something else) would be a better name than :success, I'll make the change in a blink.

I didn't do any serious search for places where the new construct would be profitably employed but there are bound to be a few. Have a look at `load-completions-from-file`, for example.

Message #35 received at 47677 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: larsi <at> gnus.org, monnier <at> iro.umontreal.ca, 47677 <at> debbugs.gnu.org
Subject: Re: bug#47677: [PATCH] condition-case success continuation
Date: Fri, 16 Apr 2021 01:13:30 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It's unfortunate that elisp has two incompatible variants,
  > throw/catch and signal/condition-case, of essentially the same
  > control structure.

It's not unfortunate, it's normal.  Other Lisp dialects have them
both, too.  There is a good reason for this: errors can invoke the
debugger.



-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Message #38 received at 47677 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: larsi <at> gnus.org, monnier <at> iro.umontreal.ca, 47677 <at> debbugs.gnu.org
Subject: Re: bug#47677: [PATCH] condition-case success continuation
Date: Fri, 16 Apr 2021 01:13:33 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It's unfortunate that elisp has two incompatible variants,
  > throw/catch and signal/condition-case, of essentially the same
  > control structure.

It's not unfortunate, it's normal.  Other Lisp dialects have them
both, too.  There is a good reason for this: errors can invoke the
debugger.

Emacs Lisp is not Scheme.  Does continuation-passing style work
usably in Emacs Lisp now?  I don't know for certain, but I would
be very surprised.

If not, let's keep things simple by not trying to define
constructs for that.  That simplicity is very important.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Message #43 received at 47677 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, 47677 <at> debbugs.gnu.org
Subject: Re: bug#47677: [PATCH] condition-case success continuation
Date: Wed, 21 Apr 2021 09:13:16 -0500

Mattias Engdegård <mattiase <at> acm.org> writes:

> 14 apr. 2021 kl. 11.29 skrev Lars Ingebrigtsen <larsi <at> gnus.org>:
>
>> Yeah, I think extending `catch' here would be less than optimal, but I
>> don't really have any suggestions here -- I use `throw/catch' so little
>> that I have no gut feeling about what I see as being useful.
>
> It's unfortunate that elisp has two incompatible variants, throw/catch and
> signal/condition-case, of essentially the same control structure. In practice
> throw/catch tends to be used more for non-error situations, but that's just a
> matter of style -- the underlying mechanisms are basically the same.
>
> In any case the patch apparently wasn't bad enough to be rejected outright so
> it's boldly been pushed to master. If the general opinion is that :no-error (or
> something else) would be a better name than :success, I'll make the change in a
> blink.
>
> I didn't do any serious search for places where the new construct
> would be profitably employed but there are bound to be a few. Have a
> look at `load-completions-from-file`, for example.

It seems like the patch here was pushed.

Should this be closed, or is there more to do here?

Message #46 received at 47677 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, 47677 <at> debbugs.gnu.org
Subject: Re: bug#47677: [PATCH] condition-case success continuation
Date: Thu, 22 Apr 2021 15:58:10 +0200

[Message part 1 (text/plain, inline)]

21 apr. 2021 kl. 16.13 skrev Stefan Kangas <stefan <at> marxist.se>:

> Should this be closed, or is there more to do here?

There's the business of fixing `catch` in the same way. (A new bug could be opened for it, but since it's intimately related we might as well do it here.) As mentioned, `catch` has three problems:

- no way to execute code when a throw is caught
- no way to execute code when the body terminates normally
- no way to catch both throws and errors

since neither `catch` nor `condition-case` compose with themselves or each other.
For example, it would be useful to have `pcase` match both the value of an expression as well as throws and errors from it.

Here is a proper patch, essentially a polished version of the previously posted diff. It adds `condition-case` clauses on the form

((:catch TAG-EXPR) BODY...)

where TAG-EXPR is evaluated before the protected form to a tag value, and BODY is executed when that tag is thrown, with the variable bound to the thrown value.

[0001-catch-handlers-in-condition-case-bug-47677.patch (application/octet-stream, attachment)]

Message #49 received at 47677 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: larsi <at> gnus.org, stefan <at> marxist.se, monnier <at> iro.umontreal.ca,
 47677 <at> debbugs.gnu.org
Subject: Re: bug#47677: [PATCH] condition-case success continuation
Date: Fri, 23 Apr 2021 00:18:06 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > There's the business of fixing `catch` in the same way. (A new bug could be opened for it, but since it's intimately related we might as well do it here.) As mentioned, `catch` has three problems:

  > - no way to execute code when a throw is caught
  > - no way to execute code when the body terminates normally
  > - no way to catch both throws and errors

I do not agree that these are problems.  catch and throw are ok
as they are, and we should leave them alone.

catch is meant for intentional exits, and condition-case is meant for
catching errors.  If you want to handle both in one place, use both
constructs there.

If you want to do something after catch catches a throw, it is not hard
to implement that using the existing constructs.

  (if (catch 'foo
         (prog1 nil
            ...do stuff...))  ;; use (throw 'foo t) to exit
      do-if-throw
     do-if-no-throw)

given how rarely this is used, it's as easy as it needs to be, and
avoids making catch complicated.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Message #52 received at 47677 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Richard Stallman <rms <at> gnu.org>
Cc: larsi <at> gnus.org, stefan <at> marxist.se, monnier <at> iro.umontreal.ca,
 47677 <at> debbugs.gnu.org
Subject: Re: bug#47677: [PATCH] condition-case success continuation
Date: Sat, 24 Apr 2021 19:02:07 +0200

23 apr. 2021 kl. 06.18 skrev Richard Stallman <rms <at> gnu.org>:

> catch and throw are ok
> as they are, and we should leave them alone.

And so we do! All we do here is to fill a few gaps in the system, but if you don't feel the need for it then you can just ignore that the new construct exist.

See the previous discussion for examples, but your code is also a good illustration:

>  (if (catch 'foo
>         (prog1 nil
>            ...do stuff...))  ;; use (throw 'foo t) to exit
>      do-if-throw
>     do-if-no-throw)

Here the throw transmits no useful value at all; if it did, this value would have to be restricted in some way, such as being non-nil. The Lisp implementation knows very well whether a throw occurred or not, so we can expose that information instead of having the user hack around the limitation.

Common uses of catch/throw include early exits from deep searches when a match is found, and then it is useful that the thrown value is unrestricted. Conversely, when `throw` is used to indicate a failure, it is useful to have the normal return value unrestricted.

The patch does not include the required documentation changes; naturally that will be remedied.

Message #58 received at 47677 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: larsi <at> gnus.org, stefan <at> marxist.se, monnier <at> iro.umontreal.ca,
 47677 <at> debbugs.gnu.org
Subject: Re: bug#47677: [PATCH] condition-case success continuation
Date: Sun, 25 Apr 2021 00:44:23 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > And so we do! All we do here is to fill a few gaps in the system,
  > but if you don't feel the need for it then you can just ignore
  > that the new construct exist.

Hold your horses!  That is not the way to look at a adding complexity
to a basic Lisp construct.

Every additional feature added to a fundamental construct increases
the complexity of the Lisp language.  That always has various kinds of
cost whether it is used or not.  Since this added feature would rarely
be of use, it would have cost and no benefit.

Please do not add this feature.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Message #61 received at 47677 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: rms <at> gnu.org
Cc: mattiase <at> acm.org, larsi <at> gnus.org, stefan <at> marxist.se,
 monnier <at> iro.umontreal.ca, 47677 <at> debbugs.gnu.org
Subject: Re: bug#47677: [PATCH] condition-case success continuation
Date: Sun, 25 Apr 2021 10:35:07 +0300

> From: Richard Stallman <rms <at> gnu.org>
> Date: Sun, 25 Apr 2021 00:44:23 -0400
> Cc: larsi <at> gnus.org, stefan <at> marxist.se, monnier <at> iro.umontreal.ca,
>  47677 <at> debbugs.gnu.org
> 
> Hold your horses!  That is not the way to look at a adding complexity
> to a basic Lisp construct.
> 
> Every additional feature added to a fundamental construct increases
> the complexity of the Lisp language.  That always has various kinds of
> cost whether it is used or not.  Since this added feature would rarely
> be of use, it would have cost and no benefit.

FTR: I agree with you.  However, sadly this seems to be a minority
opinion in the current Emacs development: features are added to Emacs
Lisp left, right and center without any serious consideration of the
of the costs and benefits balance.  The pressure to add features to
Emacs Lisp is enormous.  It sometimes seems to me that some people
regard developing and extending Emacs Lisp to be the most important
aspects of the Emacs development.

Message #64 received at 47677 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: Stefan Kangas <stefan <at> marxist.se>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, 47677 <at> debbugs.gnu.org
Subject: Re: bug#47677: [PATCH] condition-case success continuation
Date: Sun, 25 Apr 2021 18:45:31 +0200

Mattias Engdegård <mattiase <at> acm.org> writes:

>   (condition-case x
>       (throw 'meep 2)
>     ((:catch 'meep) (+ x 3)))
>   => 5
>
> Multiple catch and error handlers can be mixed freely in the same
> `condition-case` form, which can also include a :success clause.

Sorry; I'm not very enthusiastic about this construct -- it just seems
like an awkward hack to me.

condition-case is about handling errors -- it can be used as a general
flow control system, but that's an awkward fit.  It conveys intention.
So I don't think we should extend it to handle more throw/catch-like
things.

However, I do agree that Emacs Lisp could need some beefing up in the
"early return" department (which this is a kind of example of), but I
don't know what that would look like.  But I don't think it should look
like this.

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

Message #67 received at 47677 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>, "rms <at> gnu.org" <rms <at> gnu.org>
Cc: "mattiase <at> acm.org" <mattiase <at> acm.org>, "larsi <at> gnus.org" <larsi <at> gnus.org>,
 "stefan <at> marxist.se" <stefan <at> marxist.se>,
 "monnier <at> iro.umontreal.ca" <monnier <at> iro.umontreal.ca>,
 "47677 <at> debbugs.gnu.org" <47677 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#47677: [PATCH] condition-case success
 continuation
Date: Sun, 25 Apr 2021 18:21:45 +0000

> > Hold your horses!  That is not the way to look at a adding complexity
> > to a basic Lisp construct.
> >
> > Every additional feature added to a fundamental construct increases
> > the complexity of the Lisp language.  That always has various kinds
> > of cost whether it is used or not.  Since this added feature would
> > rarely be of use, it would have cost and no benefit.
> 
> FTR: I agree with you.

+1.

> However, sadly this seems to be a minority
> opinion in the current Emacs development: features are added to Emacs
> Lisp left, right and center without any serious consideration of the
> of the costs and benefits balance.  The pressure to add features to
> Emacs Lisp is enormous.  It sometimes seems to me that some people
> regard developing and extending Emacs Lisp to be the most important
> aspects of the Emacs development.

Sad, yes.  FWIW, I'm in awe of the energy and patience you
devote to Emacs development, and I hope you don't burn out.

Message #70 received at 47677 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: rms <at> gnu.org, mattiase <at> acm.org, stefan <at> marxist.se, 47677 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca, larsi <at> gnus.org
Subject: Re: [External] : bug#47677: [PATCH] condition-case success
 continuation
Date: Sun, 25 Apr 2021 21:24:23 +0300

> From: Drew Adams <drew.adams <at> oracle.com>
> CC: "mattiase <at> acm.org" <mattiase <at> acm.org>, "larsi <at> gnus.org" <larsi <at> gnus.org>,
>         "stefan <at> marxist.se" <stefan <at> marxist.se>,
>         "monnier <at> iro.umontreal.ca"
> 	<monnier <at> iro.umontreal.ca>,
>         "47677 <at> debbugs.gnu.org" <47677 <at> debbugs.gnu.org>
> Date: Sun, 25 Apr 2021 18:21:45 +0000
> 
> Sad, yes.  FWIW, I'm in awe of the energy and patience you
> devote to Emacs development, and I hope you don't burn out.

Thanks.

Message #73 received at 47677 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: mattiase <at> acm.org, larsi <at> gnus.org, stefan <at> marxist.se,
 monnier <at> iro.umontreal.ca, 47677 <at> debbugs.gnu.org
Subject: Re: bug#47677: [PATCH] condition-case success continuation
Date: Mon, 26 Apr 2021 00:40:01 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > FTR: I agree with you.  However, sadly this seems to be a minority
  > opinion in the current Emacs development: features are added to Emacs
  > Lisp left, right and center without any serious consideration of the
  > of the costs and benefits balance.  The pressure to add features to
  > Emacs Lisp is enormous.

The reason GNU packages have maintainers is so that they can make
the design decisions.  We can stand against pressure.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Message #76 received at 47677 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Stefan Kangas <stefan <at> marxist.se>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, 47677 <at> debbugs.gnu.org
Subject: Re: bug#47677: [PATCH] condition-case success continuation
Date: Mon, 26 Apr 2021 13:53:26 +0200

25 apr. 2021 kl. 18.45 skrev Lars Ingebrigtsen <larsi <at> gnus.org>:

> condition-case is about handling errors -- it can be used as a general
> flow control system, but that's an awkward fit.  It conveys intention.
> So I don't think we should extend it to handle more throw/catch-like
> things.

Most other languages use the same exception system for both errors and 'throws'; the distinction in Lisp is an artefact of history. Both are dynamically-scoped single-shot upwards-only value-conveying non-local control transfers (or described in continuation terms with about as many adjectives). The differences are minor.

Several times I've had to hack around the inability of `catch` to distinguish throws from normal termination and could go on doing so, but it feels like making function calls by manual variable assignment, stack operations and jumps. The byte code has no trouble expressing a more useful catch; it's just an arbitrary restriction in our Lisp primitives.

In addition, `catch` and `condition-case` don't compose. It would be interesting to design primitives that do but since that seems tricky (prove me wrong!), a unified `condition-case` does the job with a minimum of fuss and is definitely not a hack.

> However, I do agree that Emacs Lisp could need some beefing up in the
> "early return" department

Yes! But catch/throw is good for getting out of deep function call chains which is not quite the same thing. They are hard to optimise well for local use (exiting a loop or function) because it is difficult to prove the absence of throws elsewhere.

A variant of block/return-from would do, but better optimisations for local functions (TCO in particular) may be at least as useful.

Message #79 received at 47677 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: rms <at> gnu.org
Cc: mattiase <at> acm.org, larsi <at> gnus.org, stefan <at> marxist.se,
 monnier <at> iro.umontreal.ca, 47677 <at> debbugs.gnu.org
Subject: Re: bug#47677: [PATCH] condition-case success continuation
Date: Mon, 26 Apr 2021 15:44:37 +0300

> From: Richard Stallman <rms <at> gnu.org>
> Cc: mattiase <at> acm.org, larsi <at> gnus.org, stefan <at> marxist.se,
> 	monnier <at> iro.umontreal.ca, 47677 <at> debbugs.gnu.org
> Date: Mon, 26 Apr 2021 00:40:01 -0400
> 
>   > FTR: I agree with you.  However, sadly this seems to be a minority
>   > opinion in the current Emacs development: features are added to Emacs
>   > Lisp left, right and center without any serious consideration of the
>   > of the costs and benefits balance.  The pressure to add features to
>   > Emacs Lisp is enormous.
> 
> The reason GNU packages have maintainers is so that they can make
> the design decisions.  We can stand against pressure.

IME, that only works up to a point.  When pressure becomes high enough
and from many contributors, standing fast against it has significant
negative effects: some people become frustrated and we risk losing
them, the general atmosphere becomes unpleasant, and if nothing else,
a lot of the maintainers' time is wasted on the dispute.  And this is
assuming all the maintainers agree, which is not always the case.

The only practical way to prevent such developments IME is to convince
people that they are wrong.  And that is not easy when the subject is
not exactly the maintainer's domain of expertise.

Message #82 received at 47677 <at> debbugs.gnu.org (full text, mbox):

From: Filipp Gunbin <fgunbin <at> fastmail.fm>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: larsi <at> gnus.org, stefan <at> marxist.se, Richard Stallman <rms <at> gnu.org>,
 47677 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#47677: [PATCH] condition-case success continuation
Date: Mon, 26 Apr 2021 18:12:00 +0300

Please, let's not add such features to the basic Emacs Lisp constructs.
It's great to see Emacs Lisp being simple.

Message #85 received at 47677 <at> debbugs.gnu.org (full text, mbox):

From: Gregory Heytings <gregory <at> heytings.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 47677 <at> debbugs.gnu.org
Subject: Re: bug#47677: [PATCH] condition-case success continuation
Date: Mon, 26 Apr 2021 21:57:46 +0000

>
> This patch adds the condition-case handler syntax
>
>  (:success BODY)
>
> for code executed when the protected form terminates without error. BODY 
> is then executed with the variable bound to the result of the protected 
> form, and the result of BODY is then the value of the condition-case 
> form as usual.
>
> This plugs an annoying hole in elisp: there hasn't been any direct 
> access to the success continuation
>

Would a macro not be enough to cover that particular programming pattern? 
E.g. something like:

(defmacro success-case (value action continuation &rest handlers)
  `(catch 'success-case-fail
     ((lambda (,value) ,continuation)
      (catch 'success-case-success
        (throw 'success-case-fail
               (condition-case ,value
                   (throw 'success-case-success ,action) ,@handlers))))))

With this macro you can write for example:

(success-case result
    (read buffer)
  (use result)
  (end-of-file 'eof))

which is IMO even more concise and elegant.

Message #88 received at 47677 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: mattiase <at> acm.org, larsi <at> gnus.org, stefan <at> marxist.se,
 monnier <at> iro.umontreal.ca, 47677 <at> debbugs.gnu.org
Subject: Re: bug#47677: [PATCH] condition-case success continuation
Date: Mon, 26 Apr 2021 23:46:32 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Yes you can stand against pressure to make unwise changes.
So can I.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Message #91 received at 47677 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: larsi <at> gnus.org, stefan <at> marxist.se, monnier <at> iro.umontreal.ca,
 47677 <at> debbugs.gnu.org
Subject: Re: bug#47677: [PATCH] condition-case success continuation
Date: Mon, 26 Apr 2021 23:46:55 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Most other languages use the same exception system for both errors
  > and 'throws'; the distinction in Lisp is an artefact of history.

That's fine.  We are working with Lisp, not those other languages.

The most important thing about catch is to keep it stable.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Message #96 received at 47677-done <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Filipp Gunbin <fgunbin <at> fastmail.fm>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Stefan Kangas <stefan <at> marxist.se>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, 47677-done <at> debbugs.gnu.org
Subject: Re: bug#47677: [PATCH] condition-case success continuation
Date: Tue, 27 Apr 2021 17:31:31 +0200

26 apr. 2021 kl. 17.12 skrev Filipp Gunbin <fgunbin <at> fastmail.fm>:

> Please, let's not add such features to the basic Emacs Lisp constructs.
> It's great to see Emacs Lisp being simple.

I'd like to clear up some misconceptions here. (Filipp, this does not mean that I think that you wrote something stupid -- quite the contrary.) 

First, is Emacs Lisp really simple? Yes and no. It's not easy to tell where its boundaries are, especially since it doesn't have a proper module or namespace system or a well-defined 'core language'. Basic semantics -- control structures, built-in types, primitives and so on -- are not too messy but definitely more than they need to be; Scheme it is not. No wonder given its age; it has held up remarkably well considering, but it would be even more remarkable if modern eyes could not find flaws in it.

Second, is simplicity paramount among concerns? Clearly not: compatibility matters, and so does programming usability. It is also not clear whether a change makes a language more or less simple; adding bignums, for example, probably made the language less complex for the user. Even if (hypothetically) people got by without `unwind-protect` by catching and re-raising errors, few would object to adding that construct as a special form because it made the language less simple.

Of course you were talking about changes that make the language more difficult to use, but my point is that it is far from clear what kind of change actually does that.

Unrelated to your comment: since several people have misunderstood the proposal, I'm closing the bug to avoid conflating issues (I should have listened to Stefan Kangas); a new one can be reopened for the patch at hand when and if I get more free time.

Message #99 received at 47677 <at> debbugs.gnu.org (full text, mbox):

From: Gregory Heytings <gregory <at> heytings.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: Stefan Kangas <stefan <at> marxist.se>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 Filipp Gunbin <fgunbin <at> fastmail.fm>, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 47677 <at> debbugs.gnu.org
Subject: Re: bug#47677: [PATCH] condition-case success continuation
Date: Tue, 27 Apr 2021 19:00:53 +0000

>
> Unrelated to your comment: since several people have misunderstood the 
> proposal, I'm closing the bug
>

I guess you did not see my previous post in this bug thread.

This bug should not be closed.  I agree with Richard and Eli, it is not 
necessary to add that feature to Elisp, the more so as it can be 
implemented with a short macro:

(defmacro if-success (var action continuation &rest handlers)
  "Regain control when an error is signaled, otherwise continue.
Execute ACTION and, if no error happened, CONTINUATION, with VAR
bound to the return value of ACTION.
Otherwise, execute the appropriate HANDLER, with VAR bound to
(ERROR-SYMBOL . SIGNAL-DATA)."
  `(catch 'success-case-failure
     ((lambda (,var) ,continuation)
      (catch 'success-case-success
        (throw 'success-case-failure
               (condition-case ,var
                   (throw 'success-case-success ,action) ,@handlers))))))

Message #102 received at 47677-done <at> debbugs.gnu.org (full text, mbox):

From: Filipp Gunbin <fgunbin <at> fastmail.fm>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Stefan Kangas <stefan <at> marxist.se>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, 47677-done <at> debbugs.gnu.org
Subject: Re: bug#47677: [PATCH] condition-case success continuation
Date: Thu, 29 Apr 2021 15:45:28 +0300

Mattias,

On 27/04/2021 17:31 +0200, Mattias Engdegård wrote:

> 26 apr. 2021 kl. 17.12 skrev Filipp Gunbin <fgunbin <at> fastmail.fm>:
>
>> Please, let's not add such features to the basic Emacs Lisp constructs.
>> It's great to see Emacs Lisp being simple.
>
> I'd like to clear up some misconceptions here. (Filipp, this does not
> mean that I think that you wrote something stupid -- quite the
> contrary.)
>
> First, is Emacs Lisp really simple? Yes and no. It's not easy to tell
> where its boundaries are, especially since it doesn't have a proper
> module or namespace system or a well-defined 'core language'. Basic
> semantics -- control structures, built-in types, primitives and so on
> -- are not too messy but definitely more than they need to be; Scheme
> it is not. No wonder given its age; it has held up remarkably well
> considering, but it would be even more remarkable if modern eyes could
> not find flaws in it.
>
> Second, is simplicity paramount among concerns? Clearly not:
> compatibility matters, and so does programming usability. It is also
> not clear whether a change makes a language more or less simple;
> adding bignums, for example, probably made the language less complex
> for the user. Even if (hypothetically) people got by without
> `unwind-protect` by catching and re-raising errors, few would object
> to adding that construct as a special form because it made the
> language less simple.
>
> Of course you were talking about changes that make the language more
> difficult to use, but my point is that it is far from clear what kind
> of change actually does that.

Yes, there're no objective criteria for simplicity.  I should have
stated more clearly what I meant.  I just like that Elisp is not
overloaded with functionality and syntactic sugar.  The docstrings of
many constructs (catch in particular) are short and clear.  That allows
(relatively) easy entry for non-lispers (I remember myself 8 years or so
ago).  For more complex things, if a macro way is possible, I think it
should be preferred.

Filipp

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.