These categories are explained in more details below.
Conventional Procedural Calls
Conceptually, it is a simple category, because it has a
form traditional for the most API libraries. We only point out here,
that some of the KET modules are available in different forms: as
Windows DLLs, Sun runtime libraries, C++ object code, Delphi units, etc. Therefore, developers
can make a decision about
an appropriate version of the module.
Call conventions will depend on the version. For example,
in C++ object code we could use a call prototype like this:
essential_variables(vector<vector<string> > matr, int response,
float info_threshold, vector<int> &target_list);
so that, the call would be something like
essential_variables(matr, 15, 0.01,
where matr has type
has type vector<string>.
On the other hand, the prototype above would not be appropriate for DLLs working
in a more universal environment.
This is a 4GL calling convention, which requires less
special knowledge about the process to initiate. To give a simple
example, let's consider the called mentioned in the previous section.
The same process could be inviked in KEL as follows:
KET(find essential variables
target_file in matr_file with response 15 and
Of course, in this case too some syntactic conventions
should be observed, but the required knowledge about parameters is
rather semantic than low-level syntactic: all parameters are strings and
only their semantics is essential, also the syntax itself prompts the
order of parameters.
KEL can be used in different ways. Particularly, multiple
requests can be passed in one call (with the semicolon delimiter). In
addition to that a file name with a script can be passed instead of the
As an alternative approach, program units responding to a
KET process request can be stand-alone executables, which may have their
own GUI and can be used just as autonomic applications. This type of
interface is especially useful when the architecture of the whole system
is designed as a distributed system and/or servers have to respond both
to requests from outside and from their own GUI interface. .
KET servers are compatible with KEL, because KEL engine
transforms KEL requests into appropriate server calls.
Interpreter of KET requests more sophisticated than KEL
is SELFF engine (the abbreviation stands for "Self-referencing Forth").
Nowadays not many people remember that Forth language was one of first 4GLs. The SELFF language is not really
Forth, it just borrows several important concepts from Forth and goes
much beyond. Particularly, it incorporates a mechanism that can switch
between interpretation of a memory unit as data and program command in a
very compact and efficient way. So, the program that modifies its own
code has a quite concise representation and this becomes easy and
worth wile to do.
The approach adopted in SELFF may lead to striking
differences from conventional programming styles. For example, an
algorithm of any complexity and structure can be represented without
loops (as the reader can guess, due to recursive calls), recursive
approach is not associated with overhead and restrictions usual for
other languages and it is used much more intensively than in other programming styles.
Sometimes the host application architecture makes
it desirable to incorporate special interfacing requirements into the
interface itself instead of writing conversion-type fragments external
to KET. A typical motivation is developer's intention to streamline
inter-module interaction in favor of higher performance. KET, LLC
provides this type of services.
Knowledge Extraction Tools, LLC. 12236 Shady Hollow
Lane. Northridge, CA 91326.