bug#38252: 27.0.50; Gnus server definitions and generic function specializers

bug#38252: 27.0.50; Gnus server definitions and generic function specializers

[Eric Abrahamsen]

I'm working on changing Gnus servers into structs, and replacing the
nnoo.el architecture with generic functions, and while I think I've got
a workable roadmap I'm running into some practical confusions. Stefan
I'm ccing you directly because I suspect you're the only one who knows
the answers to my questions :)

The approach is this: Change the server interface functions in
gnus-int.el into generic functions. Provide a generalizer that
recognizes current Gnus servers, and dispatches to the current function
definitions (using `gnus-get-function' and all that). Gradually change
the in-tree backends to be defined with cl-defstruct, and use normal
dispatching-on-struct for those. Eventually the legacy generalizer would
be left in place just to deal with old-style out-of-tree backends.

As an example, here's what `gnus-request-list' currently looks like:

--8<---------------cut here---------------start------------->8---
gnus-int.el:
(defun gnus-request-list (gnus-command-method)
  (funcall (gnus-get-function gnus-command-method 'request-list)
	   (nth 1 gnus-command-method)))

nnimap.el:
(deffoo nnimap-request-list (&optional server)
 <get IMAP group list>)
--8<---------------cut here---------------end--------------->8---

Afterward it would look like this:

--8<---------------cut here---------------start------------->8---
gnus-int.el:
(cl-defgeneric gnus-request-list (server)
  "Docs and stuff.")

(cl-defmethod gnus-request-list ((server gnus-server-legacy))
  (funcall (gnus-get-function server 'request-list)
	   (nth 1 server)))

nnimap.el:
(cl-defmethod gnus-request-list ((server gnus-server-imap))
  <get IMAP group list>)
--8<---------------cut here---------------end--------------->8---

The nnimap version will dispatch on the `gnus-server-imap' defstruct,
that happens automatically. What I need is to be able to write a
generalizer/specializer that will recognize a legacy server (if calling
it "legacy" is annoying I can find something else) and dispatch on it.
The docstring of `cl-generic-define-generalizer' is gnomic, though I
found some better information in the docstring of
`cl-generic-generalizers', and looked at some of the existing
generalizer definitions.

Here's what I've worked up so far:

--8<---------------cut here---------------start------------->8---
(cl-generic-define-generalizer gnus-legacy-server-generalizer
  90 (lambda (name &rest _) `(???)
  (lambda (tag &rest _) (when (eq (car-safe tag) 'gnus-legacy-server)
			  (list tag))))

(cl-defmethod cl-generic-generalizers :extra "gnus-legacy-server" (thing)
  "Dispatch on old-style Gnus server definitions."
  (when wut?
    (list gnus-legacy-server-generalizer)))
--8<---------------cut here---------------end--------------->8---

What I'm trying to do is fairly simple: if the argument is a list, and
the head of the list is a symbol that can be assoc'd into
`nnoo-definition-alist', and the second element is a string, then it's a
gnus-legacy-server. I just don't know where that test is supposed to go,
or why.

I understand this will probably be inefficient and ugly, but I hope that
before too long it would be a rare case that the generalizer is checked
at all.

Thanks,
Eric

bug#38252: 27.0.50; Gnus server definitions and generic function specializers

[Stefan Monnier]

> I'm ccing you directly because I suspect you're the only one who knows
> the answers to my questions :)

I doubt it, there's a lot of people around here more familiar with
CLOS-style programming than I.

> --8<---------------cut here---------------start------------->8---
> gnus-int.el:
> (cl-defgeneric gnus-request-list (server)
>   "Docs and stuff.")
>
> (cl-defmethod gnus-request-list ((server gnus-server-legacy))
>   (funcall (gnus-get-function server 'request-list)
> 	   (nth 1 server)))

Why not just:

    (cl-defmethod gnus-request-list (server)
      (funcall (gnus-get-function server 'request-list)
    	       (nth 1 server)))

which means "use it as a fallback".  The downside is that it will be
used for non-legacy servers if there is no specific implementation for
that server, but presumably you can detect it and signal an appropriate
error somewhere inside gnus-get-function.

> What I'm trying to do is fairly simple: if the argument is a list, and
> the head of the list is a symbol that can be assoc'd into
> `nnoo-definition-alist', and the second element is a string, then it's a
> gnus-legacy-server.

Why not just use a `cons` specializer?

IIUC all the non-legacy servers will use structs, so you don't need to
use a specializer that's so specific that it has to check "if the
argument is a list, and the head of the list is a symbol that can be
assoc'd into `nnoo-definition-alist', and the second element is
a string".


        Stefan

bug#38252: 27.0.50; Gnus server definitions and generic function specializers

[Eric Abrahamsen]

On 11/17/19 21:03 PM, Stefan Monnier wrote:
>> I'm ccing you directly because I suspect you're the only one who knows
>> the answers to my questions :)
>
> I doubt it, there's a lot of people around here more familiar with
> CLOS-style programming than I.
>
>> --8<---------------cut here---------------start------------->8---
>> gnus-int.el:
>> (cl-defgeneric gnus-request-list (server)
>>   "Docs and stuff.")
>>
>> (cl-defmethod gnus-request-list ((server gnus-server-legacy))
>>   (funcall (gnus-get-function server 'request-list)
>> 	   (nth 1 server)))
>
> Why not just:
>
>     (cl-defmethod gnus-request-list (server)
>       (funcall (gnus-get-function server 'request-list)
>     	       (nth 1 server)))
>
> which means "use it as a fallback".  The downside is that it will be
> used for non-legacy servers if there is no specific implementation for
> that server, but presumably you can detect it and signal an appropriate
> error somewhere inside gnus-get-function.
>
>> What I'm trying to do is fairly simple: if the argument is a list, and
>> the head of the list is a symbol that can be assoc'd into
>> `nnoo-definition-alist', and the second element is a string, then it's a
>> gnus-legacy-server.
>
> Why not just use a `cons` specializer?
>
> IIUC all the non-legacy servers will use structs, so you don't need to
> use a specializer that's so specific that it has to check "if the
> argument is a list, and the head of the list is a symbol that can be
> assoc'd into `nnoo-definition-alist', and the second element is
> a string".

Okay, perhaps I was overthinking this. I don't want to assume that the
fallback is an old-style server (we might want to use the fallback for
other purposes), but you're right that 'cons is pretty much sufficient.
If anyone feeds a cons value into a Gnus server interface function that
*isn't* a server definition, that falls into "serves you right"
territory.

But just so I don't feel like I wasted my afternoon: how *would* one
write the generalizer I'm talking about?

Thanks,
Eric

bug#38252: 27.0.50; Gnus server definitions and generic function specializers

[Stefan Monnier]

> But just so I don't feel like I wasted my afternoon: how *would* one
> write the generalizer I'm talking about?

Ah, that part.
I guess It could look like (guaranteed 100% untested):

    (defvar gnus--legacy-server-tag (make-symbol "gnus-legacy-server"))
    (cl-generic-define-generalizer gnus-legacy-server-generalizer
      90 (lambda (varname &rest _)
           `(and (consp ,varname)
                 (symbolp (car ,varname))
                 (assq (car ,varname) nnoo-definition-alist)
                 (stringp (cadr ,varname))
                 gnus--legacy-server-tag))
      (lambda (tag &rest _)
        (when (eq tag gnus--legacy-server-tag) (list tag))))
    
    (cl-defmethod cl-generic-generalizers ((_ (eql gnus-legacy-server)))
      "Dispatch on old-style Gnus server definitions."
      (list gnus-legacy-server-generalizer))


-- Stefan

bug#38252: 27.0.50; Gnus server definitions and generic function specializers

[Eric Abrahamsen]

On 11/17/19 23:36 PM, Stefan Monnier wrote:
>> But just so I don't feel like I wasted my afternoon: how *would* one
>> write the generalizer I'm talking about?
>
> Ah, that part.
> I guess It could look like (guaranteed 100% untested):
>
>     (defvar gnus--legacy-server-tag (make-symbol "gnus-legacy-server"))
>     (cl-generic-define-generalizer gnus-legacy-server-generalizer
>       90 (lambda (varname &rest _)
>            `(and (consp ,varname)
>                  (symbolp (car ,varname))
>                  (assq (car ,varname) nnoo-definition-alist)
>                  (stringp (cadr ,varname))
>                  gnus--legacy-server-tag))
>       (lambda (tag &rest _)
>         (when (eq tag gnus--legacy-server-tag) (list tag))))
>     
>     (cl-defmethod cl-generic-generalizers ((_ (eql gnus-legacy-server)))
>       "Dispatch on old-style Gnus server definitions."
>       (list gnus-legacy-server-generalizer))

That's perfect, thanks. I don't need tested code, I just needed to
understand the logic of which bit is responsible for what. I wonder if
it would be useful to have an example of this, either in the manual or
cl-generic.el code comments? 

There's still a lot of work to do before struct servers and cons servers
can coexist within Gnus, but it's nice to have this piece of the puzzle
solved.