Functional programming and the logical variable

Disponible dans les fichiers attachés à ce documen

Abstract semantics for functional constraint programming

technical reportA denotational semantics is given for a lazy functional language with monotonic side-effects arising from the unification of singly-bound logical variables. The semantics is based on a Scott-style information system, which elegantly captures the notion of "constraint additin" inherent in unification. A novel feature of our approach is exploitation of the representational duality of denotations defined by information systems: (i) as domain elements in the traditional sense, and (ii) as sets of propositions or constraints. Spread care is taken to express accurately the interactions of lazy evaluation (e.g. evaluation by need), and read-only accesses of logical variables defer function applications. The purpose of our semantic description is to establish language properties such as determinacy under parallel evaluation, to validate implementation strategies, and to support the design of program analysis techniques such as those based on abstract interpretation

Combinator evaluation of functional programs with logical variables

technical reportA technique is presented that brings logical variables into the scope of the well known Turner method for evaluating normal order functioned programs by S, K, I combinator graph reduction. This extension is illustrated by SASL+LV, an extension of Turner's language SASL in which general expressions serve as formal parameters, and parameter passage is done by unification. The conceptual and practical advantages of such an extension are discussed, as well as semantic pitfalls that arise from the attendant weakening of referential transparency. Only four new combinators (LV, BV, FN and UNIFY) are introduced. The resulting object code is fully upward compatible in the sense that previously compiled SASL object code remains executable with unchanged semantics. However, "read-only" variable usage in SASL-f LV programs requires a "multi-tasking" extension of the customary stack-based evaluation method. Mechanisms are presented for managing this multi-tasking on both single and multi-processor systems. Finally, directions are examined for applying this technique to implementations involving larger granularity combinators, and fuller semantic treatment of logical variables (e.g. accommodation of failing unifications)

A Survey of Parallel Programming Constructs

This paper surveys the types of parallelism found in Functional, Lisp and Object-Oriented languages. In particular, it concentrates on the addition of high level parallel constructs to these types of languages. The traditional area of the automatic extraction of parallelism by a compiler [39] is ignored here in favor of the addition of new constructs, because the long history of such automatic techniques has shown that they are not sufficient to allow the massive parallelism promised from modem computer architectures [26. 58]. The problem then, simply stated, is given that it is now possible for us to build massively parallel machines and given that our current compilers seem incapable of generating sufficient parallelism automatically, what should the language designer do? A reasonable answer seems to be to add constructs to languages that allow the expression of additional parallelism in a natural way. Indeed that is what the designers of the the Functional, Lisp, and Object-Oriented languages described below have attempted to do. The three particular programming formalisms were picked because most of the initial ideas seem to have been generated by the designers of the functional languages and most of the current activity seems to be in the Lisp and Objected-Oriented domains. There is also a great deal of activity in the Logic programming area, but this activity is more in the area of executing the existing constructs in parallel as opposed to adding constructs specifically designed to increase parallelism

Specification-driven design of custom hardware in HOP

technical reportWe present a language "Hardware viewed as Objects and Processes" (HOP) for specifying the structure, behavior, and timing of hardware systems. HOP embodies a simple process model for lock-step synchronous processes. Processes may be described both as a black-box and as a collection of interacting sub-processes. The latter can be statically simplified using an algorithm 'PARCOMP'. PARCOMP symbolically simulates a collection of interacting processes. The advantages claimed for HOP include simple semantics, intuitiveness, high expressive power, and numerous provisions to support easily verifiable designs all the way to VLSI layout. After introducing HOP, and presenting some of the results obtained from experimenting with the HOP design system, we present the design of a large hardware system (the "Utah Simulation Engine") currently being developed to speed-up distributed discrete event simulation using Time Warp. Issues in the specification driven design of this system are discussed and illustrated using HOP

HOP: a process model for synchronous hardware systems

technical reportModules in HOP are black-boxes that are understood and used only in terms of their interface. The interface consists of d a t a ports, events, and a protocol specification that uses events and asserts/queries values to / from ports. Events are realized as different combinations of control wires or as predicates defined over data conduits. Module await either command events or status events. Data conduits are realized as bus structures that deliver the same data items at the receiving end as items sent at t h e sending end (i.e. the busses do not have any wire-permutations, tappings, etc.). HOP is useful for writing both requirements (a priori) specifications and design (a posteriori) specifications. The manner in which requirements are expressed has usually no bearing on the actual implementation chosen later. Design specifications capture known facts about a system that has been built or has been designed in detail. In a HOP based design methodology, design proceeds hierarchically, and on many occasions (but not always) top-down. For most large systems, t h e requirements specification consists of the specification of a collection of modules and not one module; for these systems, the single module view is only derived a posteriori

LEDA : a blending of imperative and relational programming

This paper describes features of a new strongly typed, compiled programming language, called LEDA. LEDA attempts to combine aspects of both imperative (value-oriented) and logical (relation-oriented) styles of programming. Logical behavior is introduced by means of a new programming structure, called a relation. Relations have similarities to functions and procedures, but are distinct from both. Several examples are presented illustrating how the combination of features from the two paradigms are mutually beneficial. Finally a short overview of the implementation is given

Low cost first class functions

We describe a. new approach to implementing functions as first class values. Using this technique, there is no additional overhead imposed for the most common case, that of non-nested functions bound at compile time. Invoking function values assigned to variables requires two additional instructions. It is only when functions are invoked which contain nested functions that can outlive their defining context that the full overhead of the construction of dynamic closures is required. The approach is being used in a new strongly typed compiled multi-paradigm programming language being developed by the author

An integration of reduction and logic for programming languages

A new declarative language is presented which captures the expressibility of both logic programming languages and functional languages. This is achieved by conditional graph rewriting, with full unification as the parameter passing mechanism. The syntax and semantics are described both formally and informally, and examples are offered to support the expressibility claim made above. The language design is of further interest due to its uniformity and the inclusion of a novel mechanism for type inference in the presence of derived type hierarchie