GNU bug report logs - #77725
31.0.50; Add support for types accepted by `cl-typep' to cl-generic?

Previous Next

Full log

View this message in rfc822 format

From: David Ponce <da_vid <at> orange.fr>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
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

Previous Next

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