Abstract: The paper addresses the design and implementation of a parallel make utility under UNIX using distributed-programming language. Current languages designed for the use in distributed programming are not yet commonly available. The basic problems of distributed programming are the creation of processes having a disjoint physical address space, and the communication among them.

Abstract: Constraint programming language do not have the notion of control flow. In contrast to Model-View-Controller change/update mechanism (which is for example exploit in the INSIST simulation system) constraint programming requires no explicit notification messages in the code of the programmer. The focus of interest has shifted from interactive physics programming of ThingLab to user interface construction of ThingLab II. The big conceptual change was in introducing an incremental constraint satisfaction component to overcome the large latency time inherent to the compilation of plans into Smalltalk methods. This effort led to the design, proof and implementation of the delta blue algorithm. In order to achieve an efficient incremental algorithm the set of constraints had to be partitioned in a constraint hierarchy. It appears to be quite natural to differentiate several levels of preference in cognitive processes. Some constraints are pivotal while others are only mildly desired. ThingLab furnishes two basics classes: required constraints, and preferential constraints. The class of preferential constraints is dichotomized further into arbitrary levels of preference. A solution comparator called locally-predicate-better finds plausible solutions at reasonable computational costs. Four basic functions are provided to interface an application with the delta blue algorithm: • add a constraint • remove a constraint • add a variable • remove a variable Possible impact to my work: Even a not too sophisticated communication network of agents is likely to be computation-cost expensive. The incremental nature of refining an application iteratively should be reflected in a constraint model. After all, a user is not willing to accept batch-like behavior (e.g., to “recompile” a dependency network) for each single modification.