Check-keyword-arguments

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

Moon writes:

``This can't work.''

Right.

Moon writes:

``In other words, don't include a procedural definition of make-instance
and don't include check-keyword-arguments as a facility that users can
call for their own purposes.  I was probably the first to suggest not
including a procedural definition, way back when, so I won't argue
against it, however I don't think you have a strong argument for it yet.''

I consider arguments of the form ``this formulation is profoundly ugly''
to be strong.  I find arguments of the form ``we need a feature
to do some task and here is a kludge that happens to work'' weak.

Moon writes:

``I don't see how this makes check-keyword-arguments less ugly.''

When you have to invent a funny representation to package up arguments
that isn't a simple list (or a property list at the worst), you are
talking ``ugly.'' 

The second argument in the revised version would be a list of methods,
which is something easy to understand.

We could describe the second argument as an alist of generic functions and
required arguments. This would be the only possible means to approach
retaining check-keyword-arguments as it is.

To show why the current formulation is uglier than some others, consider
this proposal:

Check-keyword-arguments takes a single argument, which is a list of the
form

 (keyword-plist (...(generic-function . required args) ...) . optional-keywords)

All I've done is rearrange the interface slightly; therefore its ugliness is
unchanged.  The serious point is that the funny representation of the
second argument is something that someone who is reading the definition
of a non-standard make-instance is going to have to scratch his head to
remember.

I prefer the list of methods as the second argument to check-keyword-arguments
to all other solutions. After that, the plethora of function names solution, and
finally the ditch-it solution.

			-rpg-