Christopher C. Stacy <cstacy@news.dtpq.com> wrote:
+---------------
| rpw3@rpw3.org (Rob Warnock) writes:
| > If by "required methods" you mean that a covering set of methods
| > has been defined for which a call of your generic functions will
| > never invoke NO-APPLICABLE-METHOD at run-time, then I suspect you're
| > asking for the impossible... in general, that is.
| ..
| I don't see offhand what's so hard about keeping a list of calls
| to MAKE-INSTANCE, keeping track of all constant symbols to see if
| they might ever be used as class names passed into MAKE-INSTANCE, 
| similarly maintaining function and method call graphs, and then
| computing the resulting set of CLOS methods that might be called.
| Then you check that against all the method signatures that you compiled.
| This won't match some calls that are specialized on non-CLOS types.
| But otherwise, it's just type inference, and I don't see why it
| should be impossible.
+---------------

[Last try at expressing my concern...]

I think I was more concerned that simple control-flow analysis
might not be enough to solve your problem, specifically, might
not be enough to prevent false positives -- claims of errors
that aren't. For example, suppose you have a conditional:

	(if (some-predicate foo)
	  (method-A foo)
	  (method-B foo))

where FOO is a passed-in value of some variable class. Now suppose
SOME-PREDICATE was deliberately [or accidentally!] coded as a "guard"
to keep METHOD-A from being called when the value of FOO would cause
NO-APPLICABLE-METHOD, but the tool you're asking for can't tell that --
that is, it isn't a full theorem prover on programs [which is where
the "halting problem" issue came in, a.k.a. "decidability"]. Then you
checking tool would have no choice but to report the (METHOD-A FOO)
call as a violation, because *sometimes* the IF would be executed
when FOO had a value for which there was no applicable METHOD-A
[even though SOME-PREDICATE would never let that happen].

Now you might say, "Oh, I don't care about that; I'll resolve all
the false positives manually myself." You can say that, and it even
might be true for you on the code that you write, with the checking
tool being implemented at some level, but... in *general* I believe
it is not a 100% solvable problem. Specifically, there might be input
programs for which nearly *all* the error messages from the checking
tool are false positives, which would not be good.

All I'm saying is that "it depends": on your coding style, on the
problem domain, on the total complexity of the systems you need to
check, etc. A quick & dirty heuristic algorithm might well get you
95% of what you want... or it might not.


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607