Subject: Re: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?

From: David Ponce <[email-masked]>
Date: Wed, 21 May 2025 20:59:48 +0200

On 2025-05-21 17:30, Stefan Monnier wrote:
>> My code is slightly more complex to correctly handle recursive errors:
>>
>> 1. Avoid disabling again and again the type in error following nested
>>     `condition-case'.  Currently cleanup is just a `delq', but maybe in
>>     the future it could be more, or delegated to a user function, for
>>     example.  So, IMO, the behavior should be consistent, and
>>     regardless of the error, 1 error => 1 cleanup ;-)
> 
> To me, this smells of over-engineering.

Replacing 4 lines of code with 5 is not what I would call over-engineering ;-)

> 
>> 2. Clearly mention the type in error to help fixing the issue.
>>
>> For instance eval this derived type definition, badly recursive:
>>
>>   (cl-deftype T1 ()
>>    `(satisfies ,(lambda (o) (memq 'T1 (cl-types-of o)))))
>>
>> Then: (cl-types-of "any-object")
>>
>> My proposal shows this message in the echo area:
>>
>>    Error on derived type: T1, (excessive-lisp-nesting 1601)
> 
> Errors here should be rare (and get ever more rare the more this
> functionality is used), so I don't think we should focus on making error
> messages pretty.  We should just focus on making them not debilitating
> while still allowing the usual debugging tools to do their job.

I was not focusing on making error messages pretty but error data useful ;-)

> 
> [ Also, I don't think the above error is representative of the kind of
>    errors we should expect to see.  ]

That's fine with me. After all, it was just a suggestion ;-)

David