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: Sun, 13 Apr 2025 11:53:40 -0400

> For instance, if you define an icon type like this:
>
> (defgtype icon nil ()
>   "Builtin icon type."
>   '(and symbol (satisfies iconp)))
>
> (gtype-of 'button)
> => icon
> (cl-type-of 'button)
> => symbol
>
> So you cannot have two methods with the same name, one to handle the
> symbol type, and one to handle the icon type.  I agree, it is a
> limitation.  Is this your point?

Kind of.  Note: you can.  It's just that with your current code I expect
it will misbehave (rather than signal an error).

BTW, for the above case, your code could recognize that `icon` is
a subtype of `symbol` and tell that to cl-generic.

> I wonder if in practice it is really inconvenient, and worth the
> trouble of complicate more the implementation?

I don't think I understand what compilations you're talking about, nor
what kind of inconvenience you're referring to.

> Isn't it clearer to use different methods for icons and symbols?
> Aren't these types fundamentally different, and isn't the fact that an
> icon is a symbol just an implementation choice?

The question is not whether it's desirable, but whether we can provide
an implementation that works without too many quirks.  🙂

>> BTW if you do
>>      (defgtype cons-car-foo nil ()
>>        "A cons with a `foo' car."
>>        `(satisfies ,(lambda (x) (eq (car-safe x) 'foo))))
>>      (defgtype cons-cdr-foo nil ()
>>        "A cons with a `foo' cdr."
>>        `(satisfies ,(lambda (x) (eq (cdr-safe x) 'foo))))
>> what's the `(gtype-of '(foo . foo))` ?
>
> Regarding this point, perhaps it would be possible to use an heuristic
> like: "in case of conflict, the last defined type is chosen as the
> most specific"?

I'm pretty sure some of your users will still be confused when their
methods are not used, just because some other part of their `cons` cells
happens to have a value recognized by an unrelated type.

And of course, they'd probably also be confused if the method that
handles `cons` is not used for those cons-cells.

>> Yeah, it's unsatisfactorily intricate, indeed.  It's designed first and
>> foremost to keep the dispatch "simple and reasonable fast", at the cost
>> of making `cl-generic-define-generalizer` a very sharp tool.  🙂
>> I have recently been thinking about how to make it more reliable (which
>> would also make it more flexible/powerful, allowing the definition of
>> both `and` and `or` specializers).  I have some vague idea, but there's
>> no code at all yet, and it might come with some non-trivial tradeoffs
>> (e.g. preloading the byte-compiler).
> I can't wait to see this :-)

I know I wrote "yet", but I have a very long list of "ideas I've had":
most of those will never become concrete.


        Stefan

Previous Next

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