bug#47677: [PATCH] condition-case success continuation

[Filipp Gunbin <fgunbin@fastmail.fm>]

Mattias,

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

> 26 apr. 2021 kl. 17.12 skrev Filipp Gunbin <fgunbin@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