Fix style warning about unknown :FORCE keyword arg to close-channel

[aartaka]

Hi!

Just now, loading Slynk, I got this warning:

; in: DEFUN SLYNK::CLOSE-CONNECTION%
;     (SLYNK::CLOSE-CHANNEL SLYNK::C :FORCE T)
; 
; caught STYLE-WARNING:
;   :FORCE is not a known argument keyword.

The problem was with the initial slynk::close-channel definition (a defmethod in slynk/slynk.lisp) not allowing additional keyword arguments, with slynk::close-connection providing a previously unknown argument. So I went ahead and fixed arglists with an &allow-other-keys

[aadcg]

Looks good to me, but please write commits as detailed at https://github.com/joaotavora/sly/?tab=contributing-ov-file#commit-messages.

@joaotavora kindly asked me follow that guideline.

[aartaka]

Looks good to me, but please write commits as detailed at https://github.com/joaotavora/sly/?tab=contributing-ov-file#commit-messages.

Didn’t check that, sorry. Should be fixed now!

[joaotavora]

I think the right thing to do here is to declare the keyword argument force and ignore it.

[aartaka]

I think the right thing to do here is to declare the keyword argument force and ignore it.

I mainly followed the course with &allow-other-keys because one of defmethods had (... &key), supposedly expressing the open-endedness of arglist. But alright, I’ll change it.

[joaotavora]

The CLHS has rules about the meaning of &key in a generic function. IIRC (but it was a long time ago since I looked it up), a &key in the defgeneric or in one of the methods of the generic meant all of them were &allow_other_keys. Or at least this is the way the implementation I used at the time worked since I don't remember it complaining. Anyway this would match what you wanted to do. But &allow-other-keys in general is a code smell, so if we're going to change it, might as well dtrt.

[aartaka]

The CLHS has rules about the meaning of &key in a generic function. IIRC (but it was a long time ago since I looked it up), a &key in the defgeneric or in one of the methods of the generic meant all of them were &allow_other_keys.

No, there’s &allow-other-keys for that purpose. Here’s what I found: https://cl-community-spec.github.io/pages/Congruent-Lambda_002dlists-for-all-Methods-of-a-Generic-Function.html Point 5 means roughly what you describe, but it’s for &allow-other-keys, not &key.

But &allow-other-keys in general is a code smell, so if we're going to change it, might as well dtrt.

I’m fine with that, thanks for merging!