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

Previous Next

Full log

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

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: Re: bug#77725: 31.0.50; Add support for types accepted by
 `cl-typep' to cl-generic?
Date: Tue, 29 Apr 2025 12:33:06 -0400

> Of course, it makes much sense.  If I am not wrong, the constructor of the
> class `cl-type-class' already ensures that parent types must be defined
> before their "child" types (i.e. already added to the `cl--type-list' for
> types defined with `cl-deftype").

I think so, yes.

> So it should work to simply push a new type at the beginning of the
> list.

Yup.

> And, when a type is redefined, move it at the beginning of
> the list?

Redefinition is more complicated, because child types may be in the
list, so moving the type to the head can be incorrect.  The "cheap"
solution is to leave the list unchanged (and hope the redefinition
doesn't change the hierarchy too much).

Side note: Redefinitions introduce other problems as well because the
class object's `parents` slot contains references to `cl--class`
objects, so after a redefinition via (setf (cl--find-class FOO) ...),
the children's `parents` slots point to the old class object.
That's a problem that affects all types and that we don't really try to
solve currently.

> Sorry, that's a bit paranoid of me, as I've heard many times that function
> calls are inefficient in ELisp.

FWIW, calls from bytecode to bytecode have been improved noticeable by
Mattias (can't remember if that was for Emacs-29 or Emacs-30), so it's
not as bad as it used to be.

> You're certainly right: in this case, the overhead of a function call
> should be negligible.  I'll replace those "defsubst" with "defun".

It's good to be mindful of costs, but it's also important to remember
that the majority of the code is actually not performance sensitive at
all (by which I mean that small constant factors, like what you get from
inlining, don't matter).


        Stefan

Previous Next

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