智能对象语言CLOS的分布实现

ＣＬＯＳ系统是一个嵌入Ｃｏｍｍｏｎ Ｌｉｓｐ的面向对象标准语言。文中结合所提出的类分方法，通过引入同步或异步通信协议和ＲＰＣ并发控制，详细介绍了一个新的分布ＣＬＯＳ系统ＰａｒＣＬＯＳ。     

CLOS的分布实现技术

ＣＬＯＳ系统是一个嵌入ＣｏｍｍｏｎＬｉｓｐ的面向对象标准语言，本文结合我们提出的类划分方法，通过引入同步或异步通信协议和ＲＰＣ并发控制，详细介绍了一个新的分布ＣＬＯＳ系统ＰａｒＣＬＯＳ。测试结果表明：若结点较均匀，运行效率大于８０％。     

An algebraic specification of method combination for the Common Lisp Object System

The Common Lisp Object System (CLOS) is an extension of Common Lisp for object-oriented programming being designed as part of the ANSI X3J13 Common Lisp standardization process. This report describes an algebraic specification of the method combination and application component of CLOS. The specification is based on a draft of the standard presented to the ANSI committee in spring of 1987, and was done using an executable, typed functional programming language called Axis. The result suggests a logical mapping from the abstract data types and operations in the specification to the classes and methods which could become that part of the CLOS kernel (called the metaobject protocol) involved in method combination. In addition, the existence of a formal algebraic specification for CLOS allows the effects of changes in the language to be tested during the design phase, rather than during implementation. This is illustrated by showing how the language semantics change when thecall-next-method function is allowed to take arguments, an extension proposed in the draft standard. Standardization documents like the CLOS standard are usually written in a semi-natural language, but if they are accompanied by an additional formal specifiction during their generation, the probability of undetected or lately discovered errors in the design decreases, and the specification also provides an unambiguous source of reference for implementors.     

Multimethods in C++ using recursive deferred dispatching

The author proposes a new approach for multimethod implementation in C++ based on recursive deferred dispatching. The proposed approach provides a partially broken dependency between target classes and a broken dependency between target classes and multimethods. This approach provides multimethods with strong type safety and constant execution time. A multimethod is a virtual method of several objects. Programming languages such as Dylan and the Common Lisp Object System (CLOS) allow for multimethods.     

DESIGNING COMPLEX SYSTEMS WITHIN DISTRIBUTED ARCHITECTURES: AN INTELLIGENT TUTORING SYSTEMS PERSPECTIVE

The goal of this work is to introduce the basic concepts of distributed artificial intelligence as new methodologies to conceive and realize complex intelligent systems. We focused our attention on the design of intelligent tutoring systems, and using a distributed framework, we reached a fine control on the communicability process, one of the key issues in the realization of intelligent tutoring systems. A prototype is presented as an open information system in which classical modules, such as the domain expertise module and the tutor, are seen as populations of intelligent actors that share their fragmentary knowledge and organize their tasks in a concurrent universe in order to accomplish a common goal, the teaching session. The system has been written in a concurrent object-oriented language, realized on top of the Common Lisp Object System.     

Endpaper: Technical issues of separation in function cells and value cells

Summary The bulk of arguments that focus on clean semantics and notational simplicity tend to favor uniting the function and value namespaces. In spite of this, there are those who hold strongly to a belief that a two-namespace system affords useful expressive power that they are unwilling to do without. In the end, practical considerations favor the status quo for Common Lisp. There are a large number of improvements beyond a single namespace that could be made to Common Lisp that would clean it up and simplify it. We feel that the time for such radical changes to Common Lisp has passed, and it is the job of future Lisp designers to take the lessons from Common Lisp and Scheme to produce an improved Lisp.This paper is an adaptation of a report produced for X3J13 by the authors, a technical working group engaged in standardizing Common Lisp for ANSI.     

Reflections on metaprogramming

By encapsulating aspects of language semantics within a set of default classes and allowing the programmer to derive new versions, object-oriented languages whose semantics can be tailored to the needs of individual programmers have been provided. The degree to which such languages are simultaneously flexible and efficient is an open question. We describe our experience with using this technique to incorporate transparent support for persistence into the Common Lisp Object System via its metaobject protocol, an open implementation based on reflection. For many aspects of our implementation the metaobject protocol was perfectly suitable. In other cases we had to choose between extending the protocol, requiring the application programmer to employ special idioms, and tolerating a large performance penalty. Based on our experience we evaluate the metaobject protocol, propose some improvements and extensions, and present performance measurements that reveal the need for improved language implementation techniques     

Qlisp: parallel processing in Lisp

The authors describe a version of Common Lisp for multiprocessing, called Qlisp. It supports medium-grained parallelism for artificial-intelligence and symbolic programs. Qlisp supports the futures data type. It also introduces partially, multiply invoked functions that let program components be synchronized. An implementation of Qlisp on an Alliant FX/8, based on Lucid Common Lisp, a commercial system, is described     

An integrated expert-system builder

The Expert System Builder, an AI tool kit implemented in Common Lisp on Symbolics workstations within ESPRIT Project 96 is described. The Expert System Builder system is intended to industrialize the process of building expert systems by providing developers with several powerful modeling and architectural facilities not found in most AI tool kits. To reach this goal, support for knowledge modularization and reusability were included in the system. The process of knowledge transfer is examined, as well as reasoning and control in the system. The Expert System Builder's concept system, model system, and building method are discussed. An example is given to illustrate its use     

网络化制造企业的异构系统集成控制模型

为提高制造系统的智能重构能力,快速地开发、设计和制造产品,提出网络化制造企业的异构系统集成控制模型;构建了基于公共对象请求代理体CORBA与多智能体系统MAS的企业内部集成控制体系结构,并论述了内部通信的实现机制;利用Web services技术,通过构建SOAP远程服务代理来实现合作企业间远程协同生产控制;并通过联网加工试验验证了所构建的集成控制模的可行性和实用性.     

Nonstandard Analysis in ACL2

ACL2 refers to a mathematical logic based on applicative Common Lisp, as well as to an automated theorem prover for this logic. The numeric system of ACL2 reflects that of Common Lisp, including the rational and complex-rational numbers and excluding the real and complex irrationals. In conjunction with the arithmetic completion axioms, this numeric type system makes it possible to prove the nonexistence of specific irrational numbers, such as 2. This paper describes ACL2(r), a version of ACL2 with support for the real and complex numbers. The modifications are based on nonstandard analysis, which interacts better with the discrete flavor of ACL2 than does traditional analysis.     

A verified Common Lisp implementation of Buchberger’s algorithm in ACL2

In this article, we present the formal verification of a Common Lisp implementation of Buchberger’s algorithm for computing Gröbner bases of polynomial ideals. This work is carried out in ACL2, a system which provides an integrated environment where programming (in a pure functional subset of Common Lisp) and formal verification of programs, with the assistance of a theorem prover, are possible. Our implementation is written in a real programming language and it is directly executable within the ACL2 system or any compliant Common Lisp system. We provide here snippets of real verified code, discuss the formalization details in depth, and present quantitative data about the proof effort.     

GKS in an object-oriented environment

Because of its basis properties, object-oriented programming is well suited to creating user interfaces or graphical applications. However, object-oriented systems are often without graphics or have only a graphical kernel which presents a very low level of use. Besides, such graphical kernels are dependent on the implementation. The use of graphical standards could be an alternative way to bring portability of the applications. Object-oriented systems are often implemented on top of Common Lisp or similar Lisp dialects. In this paper the implementation of an object-oriented shell of an available GKS implementation using an object-oriented extension of Common Lisp will be discussed.     

UCL+P—Defining and Implementing Persistent Common Lisp

The Persistent Lisp language was defined and an implementation, UCL+P, 1 was designed and constructed. Persistent Lisp is a superset of Common Lisp which fully supports the development of programs manipulating persistent data while maintaining Lisp semantics across the storage/retrieval of values. Persistence features provided are concurrent atomic transactions, demand loading of values, and transparent load and store of persistent values. All Common Lisp data types (with the exception of streams) can be made persistent. Nonsymbolic values are initially created as transient values on the runtime heap. When a transaction completes, transient values which are reachable from a persistent symbol become persistent. The package mechanism has been extended to add a persistence attribute to packages. When symbols are interned in a package with the persistence attribute, they become persistent, as do values reachable from them. UCL+P was created to support these features, by making extensive low-level modifications to the UCL compiler and runtime system. A new runtime data structure, the indirection vector, was created to support the relocation of newly persistent values from the runtime heap to the persistent heap.     

Landscape visualization with Emaps

Emaps, a comprehensive environment for displaying geographic data, written in object-oriented Common Lisp and running on a Macintosh computer, is described. In Emaps, a hierarchy of objects-windows, maps, cells-takes advantage of the class-instance inheritance and generic methods of Common Lisp to allow prototyping and exploring of variations. The combination of a class library of objects, a protocol for accessing them, ready access to the full display capabilities of the computer, and the interpreted nature of Lisp make for an interactive environment for visualizing landscapes and exploring geographic information     

A decision procedure for common Lisp''sSUBTYPEP predicate

Common Lisp [25],[26] includes a dynamic datatype system of moderate complexity, as well as predicates for checking the types of language objects. Additionally, an interesting predicate of two type specifiers—SUBTYPEP—is included in the language. Thissubtypep predicate provides a mechanism with which to query the Common Lisp type system regarding containment relations among the various built-in and user-defined types. Whilesubtypep is rarely needed by an applications programmer, the efficiency of a Common Lisp implementation can depend critically upon the quality of itssubtypep predicate: the run-time system typically calls uponsubtypep to decide what sort of representations to use when making arrays; the compiler calls uponsubtypep to interpret userdeclarations, on which efficient data representation and code generation decisions are based.As might be expected due to the complexity of the Common Lisp type system, there may be type containment questions which cannot be decided. In these casessubtypep is expected to return can't determine, in order to avoid giving an incorrect answer. Unfortunately, most Common Lisp implementations have abused this license by answering can't determine in all but the most trivial cases.In particular, most Common Lisp implementations of SUBTYPEP fail on the basic axioms of the Common Lisp type system itself [25][26]. This situation is particularly embarrassing for Lisp-the premier symbol processing language—in which the implementation of complex symbolic logical operations should be relatively easy. Sincesubtypep was presumably included in Common Lisp to answer thehard cases of type containment, this lazy evaluation limits the usefulness of an important language feature.     

Designing a browser to support multimethods and method combination

This paper describes some of the design considerations in developing a tool for maintaining generic functions in the proposed Common Lisp Object-Oriented System (CLOS). It is argued that tools based on class lattices provide insufficient support for programming in a language that utilizes multimethods and method combination. A new type of browser, known as a Generic Function Browser (GFB), was designed to handle the more complicated style of procedure definition offered in CLOS. Some simple example of the use of this tool are provided, along with a discussion of the philosophy underlying its design.The work described here was initially undertaken while the author was employed at Xerox AI Systems.     

Endpaper: FRPOLY: A benchmark revisited

The FRPOLY Lisp performance benchmark [3] was based on a circa-1968 piece of code for computing powers of polynomials. We address two questions: (a) What algorithm would you use if you really wanted to compute powers of polynomials fast? and (b) Given that Common Lisp supports many types of data structures other than the simple lists used for the benchmark, what more efficient representations might be appropriate to use for polynomials?