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: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: David Ponce <da_vid <at> orange.fr>
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 11:30:47 -0400

> 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.

> 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.

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


        Stefan

Previous Next

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