GCLA II(ID:5528/gcl005)


Prolog dialect from SICS

from Falkman (93):
"GCLA II is perhaps best described as a logical programming language, with some properties usually found among functional languages, and it includes hypothetical and non-monotonic reasoning as integral parts, which makes it easy to handle hypothetical queries, negation and AI-techniques like simulation and planning in a natural way. It also makes implementation of reasoning in knowledge-based systems (KBS) more direct than in Prolog"


Related languages
GCLA => GCLA II   Evolution of

References:
  • Aronsson, Martin "Methodology and Programming Techniques in GCLA II" SICS R92-05 view details Abstract: We will demonstrate various implementation techniques in the language GCLA. First an introduction to GCLA is given, followed by some examples of program developments, to demonstrate the development methodology. Other examples are also given to show various implementation techniques and properties of the system.
  • Aronsson, Martin "Implementational Issues in GCLA: A-Sufficiency and the Definiens Operation" SICS R93-02 1993 view details Abstract: We present algorithms for computing A-sufficient substitutions and constraint sets together with the definiens operation. These operations are primitive operations in the language GCLA. The paper first defines those primitives, which together form a dual rule to SLD resolution, and then describes the different algorithms and some of their properties together with examples. One of the algorithms shows how a definition can be compiled into a representation holding all possible A-sufficient substitutions/constraint sets together with their corresponding definiens. This representation makes the computation at runtime of a definiens and an A-sufficient substitution/constraint set have the same complexity as the table lookup operation clause/2 in Prolog. The paper also describes the generalisation from unification (sets of equalities) to constraint sets and satisfiability of systems of equalities and inequalities.
  • Aronsson, Martin "Implementational Issues in GCLA: Compiling Control" SICS R93-05 1993 view details Abstract: The paper describes the basic implementation of GCLA II's control level. The basis of the implementation is a compiling scheme for transforming inference rules and strategies operating on the object level to an interpreter in Prolog, where the inference rules of the control level are coded inline. This is possible since the operational semantics of the control level is deterministic, i.e. the choice of inference rule to apply on a control level goal is determined solely by the parts of the goal. To handle dynamic clauses, a context list, accessible through some new C-functions linked together with the Prolog system. GCLA I and GCLA II are described shortly, followed by a discussion of a Horn clause representation of inference rules versus functions coding inference rules. Then the transformation of inference rules and strategies is described followed by some examples.
  • Aronsson, Martin "Planning the Construction of a Building" SICS R93-03 1993 view details Abstract: The paper describes a tool for generating plans for the construction of a building. The application is implemented in GCLA, together with a simple constraint solving system. The main idea is that experiences from other plans are stored in methods; which are a systematic way of grouping activities together as higher level activities that can solve more complex tasks. Activities are entities that perform some action on a model of the real world, called the global state. Activities have preconditions, i.e. starting conditions, some representation of time and resource consumption, and postconditions, i.e. how and what to change in the global state. Scheduling activities amounts to allocating resources and placing the activities in time. The goal of the planning process, i.e what we want the planning process to achieve, is represented by a geometric model of the changed global state, i.e. a design of the specified building that one wants to build. To create plans, the system is divided into two main phases; the choice-of-method phase and the scheduling phase. In the choice-of-method phase suitable methods are chosen based on experience from the past. Such methods already exists in the building industry, although not in an explicit formal representation. Then the scheduling phase allocates resources and places the activities in time by reasoning about the activities' change of the global state. The goal of the planning process is that the objects of the specified design should be produced and represented in the global state. The user can change most of the behaviour of the system by indicating what he wants it to do. He can change activities, their preconditions, calculations and postconditions, he can change methods, or add or remove activities to them, he can change resources etc. By this flexibility, the user can form his system to reflect his own preferences about how to plan and what to plan.
  • Falkman, Göran and Jonas Warnby "Technical Diagnosis of Telecommunication Equipment - An Implementation of a Task specific Problems solving method (TDFL) using GCLA II" SICS R93-01 1993 view details Abstract: This paper describes an implementation of a small knowledge-based system in GCLA II. GCLA II is perhaps best described as a logical programming language, with some properties usually found among functional languages, and it includes hypothetical and non-monotonic reasoning as integral parts, which makes it easy to handle hypothetical queries, negation and AI-techniques like simulation and planning in a natural way. It also makes implementation of reasoning in knowledge-based systems (KBS) more direct than in Prolog. The application is an already existing KBS that guides a service technician in the task of diagnosing a specific device which is a measuring instrument for testing telecommunications equipment. The method used in the application is a problem solving method called TDFL. The TDFL method is a task specific problem solving method for technical diagnosis that gives strong support for knowledge acquisition. The method is adapted to cope with some features of the application. For example, it gives support for reducing the time required for observations and it handles parts that are not directly testable. This paper describes how to adjust the TDFL method to remedy some errors present in the original version; avoiding unnecessary search of the device and eliminating unnecessary confirmations. Some future extensions to both the TDFL method and the implementation are also presented; allowing the search for more than one fault and the possibility of turning the diagnosis backwards.