check-keyword-arguments

[Dick Gabriel <RPG@SAIL.Stanford.EDU>]

I was editing chapter 1 to reflect the change of flushing check-initargs
in favor of check-keyword-arguments when the ugliness of
check-keyword-arguments started me thinking about what check-initargs was
for.

It was a generic function, so it was originally thought useful for users
to be able to define methods for it. Now that it is a function, that
usefulness is now not thought important.

What else did it do? The primary usefulness of it was to signal an error
with all relevant information in the right place, presumably so that the
error message could be reasonable.  Well, we punted on the full specification
of that in CLOS with check-keyword-arguments because we couldn't think of
an elegant way to pass the right information around.  Moon then pointed
out that maybe we should fall back on the condition system to help solve the
problem, which is presumably the problem it is designed to solve.

So, why not take that same way out now? Presumably the slot-filler guy who
stuffs initargs into slots is able to signal an error at a reasonable
point, and that condition could be handled in make-instance etc.  The
slot-filler guy should be able check all for the existence of all the
slots he was going to try to fill, so the condition can mention all bad
slots.  Similarly, keyword arguments that are not acceptable to an
applicable method will also be signaled, and the method who notices it can
report all the keyword arguments it doesn't like or even all the
keywords the generic function and all applicable methods don't like.

The problem with this is that the user will only see one method's (or one
generic function's) worth of bad news at a time. Seeing all the possible
bad news at the same was a primary feature of check-initargs.

Another alternative is to state that the initargs will be checked at
specified points in an implementation-dependent or unspecified way.  This
isn't too bad because some of the mechanism is hidden in the current
check-keyword-arguments formulation due to the presumed use of the
condition system.  Maybe chapter 37 could describe the general mechanism
for achieving all the right stuff in the places left unspecified.

If you believe that all of the bad initargs must be determined at the same
time and you insist that the mechanism be exposed in chapters 1 and 2,
maybe it would be better for the second argument to be a list of methods
and provide a mechanism for getting all the applicable methods from a
generic function for some set of required arguments. In this way the
ugliness of check-keyword-arguments would be traded off against providing
something else useful to the user.

check-keyword-arguments keyword-argument-plist
		        methods
		        &optional extra-allowed-keywords

			-rpg-