"fall-through" generic function args plus &context

"fall-through" generic function args plus &context

[Eric Abrahamsen]

I have a few defmethods that use the &context construct to dispatch on
the value of major mode:

(cl-defmethod my-make-buffer-name (&context (major-mode gnus-summary-mode))
  ;; etc...
  )

I need a catch-all method, for default behavior when we're in other
modes that aren't targeted by an existing method.

I've tried things like:

(&context _major-mode)
(&context (major-mode t))
(&context (major-mode nil))
(&context (major-mode (eql _nuthin))

And a few other things. Everything raises cl-no-applicable-method.

What's the correct way to do this? Or do I need to override
`cl-no-applicable-method' and catch the error?

Thanks,
Eric

Re: "fall-through" generic function args plus &context

[Eric Abrahamsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> I have a few defmethods that use the &context construct to dispatch on
> the value of major mode:
>
> (cl-defmethod my-make-buffer-name (&context (major-mode gnus-summary-mode))
>   ;; etc...
>   )
>
> I need a catch-all method, for default behavior when we're in other
> modes that aren't targeted by an existing method.
>
> I've tried things like:
>
> (&context _major-mode)
> (&context (major-mode t))
> (&context (major-mode nil))
> (&context (major-mode (eql _nuthin))
>
> And a few other things. Everything raises cl-no-applicable-method.
>
> What's the correct way to do this? Or do I need to override
> `cl-no-applicable-method' and catch the error?

Come to think of it, how does one override `cl-no-applicable-method' for
a specific generic? The defgeneric looks like:

(cl-defgeneric cl-no-applicable-method (generic &rest args)
  "Function called when a method call finds no applicable method."
  (signal 'cl-no-applicable-method `(,(cl--generic-name generic) ,@args)))

How do I specialize on "generic"?

Thanks,
Eric

Re: "fall-through" generic function args plus &context

[Stefan Monnier]

> Come to think of it, how does one override `cl-no-applicable-method' for
> a specific generic?

Good question.

I guess in CLOS, this works by creating a new class that derives from
the standard "generic function" class, then make your generic function
be an instance of *that* class, at which point you can then define your
`cl-no-applicable-method` method which specializes on the class of the
`generic` argument.

But currently cl-generic does not support this notion of "generic
function" quite the way CLOS does (for one our "generic functions"
objects are `defstruct` rather than `defclass` objects, and also
they're not callable so the function cell is yet different (a fairly
standard closure)).


        Stefan

Re: "fall-through" generic function args plus &context

[Eric Abrahamsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Come to think of it, how does one override `cl-no-applicable-method' for
>> a specific generic?
>
> Good question.
>
> I guess in CLOS, this works by creating a new class that derives from
> the standard "generic function" class, then make your generic function
> be an instance of *that* class, at which point you can then define your
> `cl-no-applicable-method` method which specializes on the class of the
> `generic` argument.
>
> But currently cl-generic does not support this notion of "generic
> function" quite the way CLOS does (for one our "generic functions"
> objects are `defstruct` rather than `defclass` objects, and also
> they're not callable so the function cell is yet different (a fairly
> standard closure)).

Thanks for the tips! Using fundamental-mode didn't work (at least not in
the emacs-lisp buffer I tested it in), but the empty arg-list did, so
that's sorted.

I haven't looked too hard at the specializer code, but if we can already
dispatch on defstructs, it seems like it wouldn't be that hard to make
something that dispatches on generics? But I really don't know...

Thanks again,
Eric

Re: "fall-through" generic function args plus &context

[Stefan Monnier]

>> But currently cl-generic does not support this notion of "generic
>> function" quite the way CLOS does (for one our "generic functions"
>> objects are `defstruct` rather than `defclass` objects, and also
>> they're not callable so the function cell is yet different (a fairly
>> standard closure)).

> Thanks for the tips! Using fundamental-mode didn't work (at least not in
> the emacs-lisp buffer I tested it in),

Hmm... indeed we don't register fundamental-mode as a parent for
some reason.  I think either (&context (major-mode nil)) or (&context
(major-mode fundamental-mode)) or both should work.

> but the empty arg-list did, so that's sorted.

That's the better choice anyway (it's marginally more efficient).

> I haven't looked too hard at the specializer code, but if we can already
> dispatch on defstructs, it seems like it wouldn't be that hard to make
> something that dispatches on generics?

Yes, it shouldn't be too hard, but it still requires offering the
possibility to use a "child defstruct" for a given generic function
(currently, all generic function objects are deftruct of the same type,
so there's not much dispatch to do).
IOW implement the :generic-function-class arg to `cl-defgeneric` as well
as well as exposing the `cl--generic` type (i.e. renaming it) so users
can define child defstructs.


        Stefan

Re: "fall-through" generic function args plus &context

[Eric Abrahamsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> But currently cl-generic does not support this notion of "generic
>>> function" quite the way CLOS does (for one our "generic functions"
>>> objects are `defstruct` rather than `defclass` objects, and also
>>> they're not callable so the function cell is yet different (a fairly
>>> standard closure)).
>
>> Thanks for the tips! Using fundamental-mode didn't work (at least not in
>> the emacs-lisp buffer I tested it in),
>
> Hmm... indeed we don't register fundamental-mode as a parent for
> some reason.  I think either (&context (major-mode nil)) or (&context
> (major-mode fundamental-mode)) or both should work.

Perhaps fundamental-mode should work, but I intuitively tried (&context
(major-mode nil)) and (&context (major-mode t)).

Also, so far as I can tell, the correct function signature for the
defgeneric should be (&context (major-mode t)), is that correct? At
least, that didn't raise any errors.

>> but the empty arg-list did, so that's sorted.
>
> That's the better choice anyway (it's marginally more efficient).
>
>> I haven't looked too hard at the specializer code, but if we can already
>> dispatch on defstructs, it seems like it wouldn't be that hard to make
>> something that dispatches on generics?
>
> Yes, it shouldn't be too hard, but it still requires offering the
> possibility to use a "child defstruct" for a given generic function
> (currently, all generic function objects are deftruct of the same type,
> so there's not much dispatch to do).
> IOW implement the :generic-function-class arg to `cl-defgeneric` as well
> as well as exposing the `cl--generic` type (i.e. renaming it) so users
> can define child defstructs.

I get it in theory, but don't understand specializers well enough to
know where to start. One of my projects for the next year is learning
generic functions better, so let's see if I get to it before anyone else
does.

Thanks,
Eric

Re: "fall-through" generic function args plus &context

[Stefan Monnier]

> Perhaps fundamental-mode should work, but I intuitively tried (&context
> (major-mode nil)) and (&context (major-mode t)).

By "should" I meant that it's a bug that neither works.

> Also, so far as I can tell, the correct function signature for the
> defgeneric should be (&context (major-mode t)), is that correct?
> At least, that didn't raise any errors.

cl-defgeneric doesn't actually pay attention to the signature you provide.


        Stefan

Re: "fall-through" generic function args plus &context

[Eric Abrahamsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Perhaps fundamental-mode should work, but I intuitively tried (&context
>> (major-mode nil)) and (&context (major-mode t)).
>
> By "should" I meant that it's a bug that neither works.

Right, I got that. I'll open a bug report.

>> Also, so far as I can tell, the correct function signature for the
>> defgeneric should be (&context (major-mode t)), is that correct?
>> At least, that didn't raise any errors.
>
> cl-defgeneric doesn't actually pay attention to the signature you provide.

Heartbreaking!

Thanks,
Eric

Re: "fall-through" generic function args plus &context

[Stefan Monnier]

>>> Also, so far as I can tell, the correct function signature for the
>>> defgeneric should be (&context (major-mode t)), is that correct?
>>> At least, that didn't raise any errors.
>> cl-defgeneric doesn't actually pay attention to the signature you provide.
> Heartbreaking!

But don't worry: it's still good for karma to put a good signature.


        Stefan

Re: "fall-through" generic function args plus &context

[Stefan Monnier]

> I need a catch-all method, for default behavior when we're in other
> modes that aren't targeted by an existing method.
>
> I've tried things like:
>
> (&context _major-mode)
> (&context (major-mode t))
> (&context (major-mode nil))
> (&context (major-mode (eql _nuthin))

You could try

    ()
or
    (&context (major-mode fundamental-mode))


-- Stefan