key args listing don't show

[josa1965]

after a function or method, hitting space list the arguments. this works for "normal" args, &rest but not for &key args. only "(&key)" shows.

[gb]

In general, keyword arguments are displayed in the echo area.

If there's a specific case where they aren't and should be, please describe that case.

[josa1965]

i am talking about the echo area. (but didnt knew the therm). as it seems : defuns show the &key arguments correctly. defmethods does not.

[gb]

Method functions that take &key arguments have those arguments displayed in the echo area in general.

Again, if there is a specific case where this does not happen, please provide it as an example.

[josa1965]

(defmethod func (&key arg1 arg2) ()) (func

(defun func2 (&key arg1 arg2) ()) (func2

func does not show the arg1 and arg2 names in the echo area. func2 does.

[gb]

Are you really talking about the case where a generic function has no specialized arguments but accepts &key ?

In the general case (where a generic function accepts at least one required/specializable argument and its methods accept &key arguments), the generic function's lambda list merely contains &key; individual methods can accept different sets of keywords, and it's not meaningful or useful to say that the generic function accepts a particular set of keyword arguments (what arguments are actually accepted depends on what methods are applicable.)

It's sometimes useful to declare that (all methods on) a particular generic function will accept (at least) a particular set of keyword arguments:

(defgeneric draw-character ((c character) (s view) &key font color))

so it's meaningful to say that "the arglist of the function DRAW-CHARACTER is (c s &key font color)", even though it's possible to define methods that accept additional keyword arguments. Without the DEFGENERIC, it's not really meaningful.

In the case where only a single method is defined on a generic function (and in your specializer-less example, only a single primary method can ever be defined) we could conceivably say that the generic function's arglist is the sole method function's arglist, but (except in the specializer-less case) that'd mean that the generic function's arglist would change as soon as a second method was defined.

If it's meaningful to talk about the set of keyword arguments accepted by a generic function, then the only way to define that set is to use DEFGENERIC (or the functional MOP equivalent.)

[alms]

This is marked as an IDE ticket, not an ANSII CL or Compiler ticket. So I've reopened it and changed it from a defect to an enhancement. I also gave it milestone that indicates it's not part of the current round IDE work.

GB is of course correct about the keyword arguments to generic functions. That said, the IDE could still be more helpful than it currently is. I can think of a couple of ways to handle this.

If all of the methods on a generic function have the same keywords, then it could echo those keywords when it echoes the argument list. This seems like it should be straightforward and a good thing to do.

If the methods have different keywords, we could consider echoing all of the keywords, maybe using font colors or something to distinguish those which are used by all the methods and those which are only used by some. I think this would be helpful, but others might find it confusing.

[gz]

FWIW, Slime just shows the union of keywords from all methods. This seems good enough to me. Visually distinguishing keywords from different methods doesn't feel like it'd add anything helpful to the user.

[gb]

Given something like:

(defmethod foo ((a x) &key b)
  ...)

(defmethod foo ((a y) &key c)
  ...)

I don't think that announcing that FOO's arglist is something like (A &KEY B C) is "good enough"; the version of Slime that I have installed doesn't seem to think so either (when running CCL), and reports it as (A &KEY).

For the record, MCL's ARGLIST function basically returned the arglist of an arbitrary method (the first thing that it found on the GENERIC-FUNCTION-METHODS list); that isn't really right either in general - it wouldn't be in a case like the above, at least half the time - but it sometimes was and people didn't notice or care. (Or they sent mail to bug-mcl and got spam back. Who knows ?)

For (the effective/current definition of) a non-generic function, the set of keywords it accepts is essentially fixed (ignoring &ALLOW-OTHER-KEYS). For generic functions, this isn't generally true: both the union and the intersection of the (possibly) acceptable keywords can change as methods are added, so anything that we could possibly say about the keyword args accepted by a generic function has to be taken with at least a small grain of salt: it's provisional, pending further method definitions.

There are exactly 3 generic functions (CLOSE, CCL:SHUTDOWN, and CCL:ACCEPT-CONNECTION) in CCL itself whose methods accept specific keyword arguments; in all 3 cases, all methods on the GF accept exactly the same keyword arguments (and it happens to be the case that all of these methods accept exactly one keyword argument.) It's certainly legal for different methods on a generic function to accept different sets of keyword arguments, but it's not clear that this is common practice and it may be sort of hard to exploit (one may have to use :ALLOW-OTHER-KEYS T, or have a really good idea of what the effective method will be, or use some data-driven mechanism to construct an arglist ...) I don't think that it'd be tremendously useful to show the union of all keyword arguments in the case where the union differs from the intersection, and can't really think of a better solution than to have ARGLIST show the interesection of the keyword args accepted by existing methods.

(Yes, that's different from the status quo and different from what I was advocating last week.)