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

Previous Next

Package: emacs;

Reported by: David Ponce <da_vid <at> orange.fr>

Date: Fri, 11 Apr 2025 07:16:01 UTC

Severity: normal

Found in version 31.0.50

Full log


Message #131 received at 77725 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#77725: 31.0.50; Add support for types accepted by `cl-typep'
 to cl-generic?
Date: Mon, 28 Apr 2025 12:56:35 +0200
[Message part 1 (text/plain, inline)]
On 2025-04-27 17:31, David Ponce wrote:
> On 2025-04-27 14:59, Stefan Monnier wrote:
>>>> Exactly, I fully agree, the question is "how to keep track of the
>>>> children"?
>>>
>>> You could approximate it with `after-load-functions`.  Or, with the
>>> proposed patch, you could use an advice on `cl--type-deftype`.  Once you
>>> do that, you won't need to break circularity in `cl-types-of`.
>>
>> I think what I was trying to say all along is:
>> the circularity you're trying to break doesn't come from `cl-deftype` or
>> `cl-types-of` but from your impredicative definition of `T1`.
>> So it'd be best to fix it there:
>>
>>      (cl-deftype T1 ()
>>        `(satisfies ,(lambda (o) (memq 'T1 (cl-types-of o)))))
>>
>> =>
>>
>>      (defvar my-pending-T1-check (make-symbol "void"))
>>
>>      (cl-deftype T1 ()
>>        `(satisfies
>>          ,(lambda (o)
>>             (and (not (eq o my-pending-T1-check))
>>                  (let ((my-pending-T1-check o))
>>                    (memq 'T1 (cl-types-of o)))))))
>>
> 
> Hi Stefan,
> 
> I quite like this approach, where it's not `cl-types-of', but each type
> that bears responsibility for its implementation.
> 
> So, if I understand correctly, your recommendation is to not try to solve
> recursion (or other) problems in `cl-types-of' at all, but rather at the
> level of each type's definition, and to let ill-defined types possibly
> cause errors?
> 
> The only point that still bothers me is not protecting `cl-types-of' from
> errors due to ill-defined types.  This is particularly true because this
> can impact the entire Emacs session if certain methods are prevented from
> working, such as those involved in the display process (I use such methods
> based on `cl-deftype' for example, in my own alternative implementation of
> icons and tab-line).
> 
> If you agree I will update cl-types.el accordingly and dispatch it in
> the existing libraries according to your previous proposal... to see what
> happens ;-)
> 
> Thanks again for being so helpful!
> 
> David

Please find attached a new version of cl-types.el, where any attempt to work
around type definition errors with `cl-types-of' has been removed.  If such
an error occurs, it is now clearly signaled by `warn', and the affected type
is marked as "in error" and ignored until its next redefinition or deletion.

WDYT?
[cl-types.el (text/x-emacs-lisp, attachment)]

This bug report was last modified 10 days ago.

Previous Next


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