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, 7 May 2025 19:06:19 +0200

On 2025-05-07 18:19, Stefan Monnier wrote:
>> Yes, `message' will definitely work better, but errors will be less
>> highlighted.  But a message is always better than nothing ;-)
>>
>> I wouldn't want ill-defined types entering infinite recursion to
>> break error handling, just because the depth limit is reached,
> 
> As I said, this is a general problem.  Do you have reasons to believe it
> is much more prevalent here than elsewhere?

Without error handling, types that follow a type in error will not be
considered, so the corresponding methods will not be dispatched, so
other errors, etc.

I tried to issue a plain `message' instead of calling `warn', and it
works nicely without the need to increase recursion depth in
relevant cases.  Valid types are still usable, and the message clearly
mention the type that encountered a problem, and what the problem is.
So, for me, it is a clear benefit ;-)

[...]
> I like `mapcar`, but indeed here we do want the reversal that
> dolist+push gives us "for free".  I haven't pushed your patch yet
> because git.sv.gnu.org is not responding, but I'll do it "soonish".

Thank you!
 
>> Please find attached another small patch for the method
>> `cl-generic-generalizers' in cl-lib.el.
>>
>> It ensures that the derived type is still present in the
>> `cl--type-list', in order to signal an "unkonw specializer"
>> error, if the type was removed from the list because it
>> was in error.
> 
> But this can lead to the weird "unknown specializer" error for a type
> which *is* known (just defined poorly enough that it signaled an error
> at some point).

On the other hand, I don't see what advantage there is in allowing the
definition of new methods based on a type that cannot be dispatched
because it is in error.  Unless perhaps these methods become functional
again without doing anything when the type definition has been
fixed.  In this case, I agree it is better not to block
anything.  So I will rely on your experience in this area ;-)

David

Previous Next

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