Compiling knowledge-based systems from KEE to Ada

The dominant technology for developing AI applications is to work in a multi-mechanism, integrated, knowledge-based system (KBS) development environment. Unfortunately, systems developed in such environments are inappropriate for delivering many applications - most importantly, they carry the baggage of the entire Lisp environment and are not written in conventional languages. One resolution of this problem would be to compile applications from complex environments to conventional languages. Here the first efforts to develop a system for compiling KBS developed in KEE to Ada (trademark). This system is called KATYDID, for KEE/Ada Translation Yields Development Into Delivery. KATYDID includes early prototypes of a run-time KEE core (object-structure) library module for Ada, and translation mechanisms for knowledge structures, rules, and Lisp code to Ada. Using these tools, part of a simple expert system was compiled (not quite automatically) to run in a purely Ada environment. This experience has given us various insights on Ada as an artificial intelligence programming language, potential solutions of some of the engineering difficulties encountered in early work, and inspiration on future system development

Kawa|compiling dynamic languages to the Java VM

Many are interested in Java for its portable bytecodes and extensive libraries, but prefer a different language, especially for scripting. People have implemented other languages using an interpreter (which is slow), or by translating into Java source (with poor responsiveness for eval). Kawa uses an interpreter only for “simple” expressions; all non-trivial expressions (such as function definitions) are compiled into Java bytecodes, which are emitted into an in-memory byte array. This can be saved for later, or quickly loaded using the Java ClassLoader. Kawa is intended to be a framework that supports multiple source languages. Currently, it only supports Scheme, which is a lexically-scoped language in the Lisp family. The Kawa dialect of Scheme implements almost all of the current Scheme standard (R5RS), with a number of extensions, and is written in a efficient objectoriented style. It includes the full “numeric tower”, with complex numbers, exact infinite-precision rational arithmetic, and units. A number of extensions provide access to Java primitives, and some Java methods provide convenient access to Scheme. Since all Java objects are Scheme values and vice versa, this makes for a very powerful hybrid Java/Scheme environment. An implementation of ECMAScript (the standardized “core ” of JavaScript) is under construction. Other languages, including Emacs Lisp, are also being considered

Benchmarking implementations of functional languages with ‘Pseudoknot', a float-intensive benchmark

Over 25 implementations of different functional languages are benchmarked using the same program, a floating-point intensive application taken from molecular biology. The principal aspects studied are compile time and execution time for the various implementations that were benchmarked. An important consideration is how the program can be modified and tuned to obtain maximal performance on each language implementation. With few exceptions, the compilers take a significant amount of time to compile this program, though most compilers were faster than the then current GNU C compiler (GCC version 2.5.8). Compilers that generate C or Lisp are often slower than those that generate native code directly: the cost of compiling the intermediate form is normally a large fraction of the total compilation time. There is no clear distinction between the runtime performance of eager and lazy implementations when appropriate annotations are used: lazy implementations have clearly come of age when it comes to implementing largely strict applications, such as the Pseudoknot program. The speed of C can be approached by some implementations, but to achieve this performance, special measures such as strictness annotations are required by non-strict implementations. The benchmark results have to be interpreted with care. Firstly, a benchmark based on a single program cannot cover a wide spectrum of ‘typical' applications. Secondly, the compilers vary in the kind and level of optimisations offered, so the effort required to obtain an optimal version of the program is similarly varie

The nature and evaluation of commercial expert system building tools, revision 1

This memorandum reviews the factors that constitute an Expert System Building Tool (ESBT) and evaluates current tools in terms of these factors. Evaluation of these tools is based on their structure and their alternative forms of knowledge representation, inference mechanisms and developer end-user interfaces. Next, functional capabilities, such as diagnosis and design, are related to alternative forms of mechanization. The characteristics and capabilities of existing commercial tools are then reviewed in terms of these criteria

Benchmarking Implementations of Functional Languages with ``Pseudoknot'', a Float-Intensive Benchmark

Over 25 implementations of different functional languages are benchmarked using the same program, a floatingpoint intensive application taken from molecular biology. The principal aspects studied are compile time and execution time for the various implementations that were benchmarked. An important consideration is how the program can be modified and tuned to obtain maximal performance on each language implementation.\ud With few exceptions, the compilers take a significant amount of time to compile this program, though most compilers were faster than the then current GNU C compiler (GCC version 2.5.8). Compilers that generate C or Lisp are often slower than those that generate native code directly: the cost of compiling the intermediate form is normally a large fraction of the total compilation time.\ud There is no clear distinction between the runtime performance of eager and lazy implementations when appropriate annotations are used: lazy implementations have clearly come of age when it comes to implementing largely strict applications, such as the Pseudoknot program. The speed of C can be approached by some implemtations, but to achieve this performance, special measures such as strictness annotations are required by non-strict implementations.\ud The benchmark results have to be interpreted with care. Firstly, a benchmark based on a single program cannot cover a wide spectrum of 'typical' applications.j Secondly, the compilers vary in the kind and level of optimisations offered, so the effort required to obtain an optimal version of the program is similarly varied

On the basis for ELF - An Extensible Language Facility

Computer language for data processing and information retrieva

Denotational style correctness of a CPS-Transform based compiler

RIT department of computer science technical report. Correctness is a crucial property for compilers; programmers rely on it when writing code. Ideally, correctness should be proved. Work on compiler correctness has focused on direct translation strategies. However, in practice, the continuation passing style (CPS) transform (or a variant) is often used in the translation process. Here a simple source language and its CPS-transform based compiler are introduced. A tractable proof for this compiler is presented, including a denotational proof of the correctness of a CPS-transform. The benefits of the proof are discussed