"Tobias C. Rittweiler" <tcr@...> writes:
> the attached patch stores the arglist of DEFTYPE forms in the globaldb,
> where they can be retrieved via `(info :type :deftype-arglist 'foo)'.
>
> Additionally an introspection function DEFTYPE-LAMBDA-LIST is created in
> SB-INTROSPECT that just wraps around the above form.
>
> Test cases included.
I've built and tested this, and it more-or-less works. But...
... I'm not sure that this is the "right way"; if it is, then there's
some associated work to make macro lambda lists work similarly, while
if it isn't it would probably be better to parallel macro lambda
lists' strategy.
How do macro lambda lists work? Well, in defmacro's guts, we
eventually set the arglist of the macro-function to the arglist that
we want, and then all we have to do to show a macro's arglist is
retrieve the macro-function and use function arglist. The parallel
case for deftype would be to retrieve the expander function and use
the arglist of that, which is currently an uninteresting (#:WHOLENNN)
Why would this be better? Well, it stores the information only in one
place, which means that there's not any kind of difficulty with
keeping all the information consistent: your patch loses in the
following case:
(deftype foo (x) `(bar ,x))
(defclass foo () ())
(sb-int:info :type :deftype-arglist 'foo)
So I think that using a similar trick to defmacro is a better approach.
That said, the defmacro trick is currently not completely watertight;
it loses if *evaluator-mode* is :interpret:
(setf *evaluator-mode* :interpret)
(defmacro foo (x) `(bar ,x))
(sb-introspect:function-arglist 'foo)
so there's work to do there, too -- it's not just a blind copy.
(Also, the comment in the sb-introspect test driver refers to
presumably an older name for the operator you're introducing.)
Best,
Christophe