[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
suitability of CLOS for large KB
- To: BALL%YALEMED.BITNET@CUNYVM.CUNY.EDU
- Subject: suitability of CLOS for large KB
- From: Jon L White <jonl@lucid.com>
- Date: Thu, 19 Jul 90 14:54:41 PDT
- Cc: commonLoops.PA@Xerox.COM
- In-reply-to: <BALL%YALEMED.BITNET@CUNYVM.CUNY.EDU>'s message of Thu, 12 Jul 90 19:12 EST <900712-161359-7007@Xerox>
- Redistributed: commonLoops.PA
Shel,
I've read the responses so far to your quest, and want to add my
concurrance to those who say that the critique out of context just
isn't specific enough to know what is at the heart of the problem.
However, let me give you a hypothetical but very specific criticism
of one attempt to implement a database in CLOS. I mean this only as
a sample of how specific one would want to be in criticism, rather than
to suggest that it applies in your case.
Ocasionally, a programmer will distribute some data using class- and
EQL- specialization on generic functions, and the volume of such reaches
the point where he clearly has a database problem rather than a generic-
function one. The use of these CLOS features -- which have a kind of
database underlying them -- to circumvent the use of more standard data-
basing packages or techniques is surely inappropriate. It is worth
noting that EQL specialization isn't even intended to be a replacement
for the rather limited kind of "database" tool already found in Common
Lisp, namely Hash Tables.
I used the term "database" rather than the one you mentioned ("Knowledge
Base"); this is to make the hypothetical criticism more clear, and allow for
some fuzziness as to what constitutes a "Knowledge Base". Note also that
the relative efficiency of generic-function dispatch versus hash-tables or
database isn't specifically in question here, although that should be a
legitimate area of concern to the programmer.
Of course, the judgement of whether or not one is perverting the use of
generic-function specialization could vary from reviewer to reviewer.
-- JonL --