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?