Showing papers on "Functional logic programming published in 1999"

Logic programs with stable model semantics as a constraint programming paradigm

Abstract: Logic programming with the stable model semantics is put forward as a novel constraint programming paradigm. This paradigm is interesting because it bring advantages of logic programming based knowledge representation techniques to constraint programming and because implementation methods for the stable model semantics for ground (variabledfree) programs have advanced significantly in recent years. For a program with variables these methods need a grounding procedure for generating a variabledfree program. As a practical approach to handling the grounding problem a subclass of logic programs, domain restricted programs, is proposed. This subclass enables efficient grounding procedures and serves as a basis for integrating builtdin predicates and functions often needed in applications. It is shown that the novel paradigm embeds classical logical satisfiability and standard (finite domain) constraint satisfaction problems but seems to provide a more expressive framework from a knowledge representation point of view. The first steps towards a programming methodology for the new paradigm are taken by presenting solutions to standard constraint satisfaction problems, combinatorial graph problems and planning problems. An efficient implementation of the paradigm based on domain restricted programs has been developed. This is an extension of a previous implementation of the stable model semantics, the Smodels system, and is publicly available. It contains, e.g., builtdin integer arithmetic integrated to stable model computation. The implementation is described briefly and some test results illustrating the current level of performance are reported.

Stable Models and an Alternative Logic Programming Paradigm

Abstract: In this paper we reexamine the place and role of stable model semantics in logic programming and contrast it with a least Herbrand model approach to Horn programs We demonstrate that inherent features of stable model semantics naturally lead to a logic programming system that offers an interesting alternative to more traditional logic programming styles of Horn logic programming, stratified logic programming and logic programming with well-founded semantics The proposed approach is based on the interpretation of program clauses as constraints In this setting, a program does not describe a single intended model, but a family of its stable models These stable models encode solutions to the constraint satisfaction problem described by the program Our approach imposes restrictions on the syntax of logic programs In particular, function symbols are eliminated from the language We argue that the resulting logic programming system is well-attuned to problems in the class NP, has a well-defined domain of applications, and an emerging methodology of programming We point out that what makes the whole approach viable is recent progress in implementations of algorithms to compute stable models of propositional logic programs

The OPL optimization programming language

Abstract: Part 1 The language: a short tour of OPL models data modelling expressions and constraints formal parameters search display. Part 2 The application areas: linear and integer programming constraint programming scheduling.

Agent Programming in 3APL

Abstract: An intriguing and relatively new metaphor in the programming community is that of an intelligent agent. The idea is to view programs as intelligent agents acting on our behalf. By using the metaphor of intelligent agents the programmer views programs as entities which have a mental state consisting of beliefs and goals. The computational behaviour of an agent is explained in terms of the decisions the agent makes on the basis of its mental state. It is assumed that this way of looking at programs may enhance the design and development of complex computational systems. To support this new style of programming, we propose the agent programming language 3APL. 3APL has a clear and formally defined semantics. The operational semantics of the language is defined by means of transition systems. 3APL is a combination of imperative and logic programming. From imperative programming the language inherits the full range of regular programming constructs, including recursive procedures, and a notion of state-based computation. States of agents, however, are belief or knowledge bases, which are different from the usual variable assignments of imperative programming. From logic programming, the language inherits the proof as computation model as a basic means of computation for querying the belief base of an agent. These features are well-understood and provide a solid basis for a structured agent programming language. Moreover, on top of that 3APL agents use so-called practical reasoning rules which extend the familiar recursive rules of imperative programming in several ways. Practical reasoning rules can be used to monitor and revise the goals of an agent, and provide an agent with reflective capabilities. Applying the metaphor of intelligent agents means taking a design stance. From this perspective, a program is taken as an entity with a mental state, which acts pro-actively and reactively, and has reflective capabilities. We illustrate how the metaphor of intelligent agents is supported by the programming language. We also discuss the design of control structures for rule-based agent languages. A control structure provides a solution to the problem of which goals and which rules an agent should select. We provide a concrete and intuitive ordering on the practical reasoning rules on which such a selection mechanism can be based. The ordering is based on the metaphor of intelligent agents. Furthermore, we provide a language with a formal semantics for programming control structures. The main idea is not to integrate this language into the agent language itself, but to provide the facilities for programming control structures at a meta level. The operational semantics is accordingly specified at the meta level, by means of a meta transition system.

Concurrent Programming in ML

Abstract: Concurrent Programming ML (CML), included as part of the SML of New Jersey (SML/NJ) distribution, combines the best features of concurrent programming and functional programming. This practical, "how-to" book focuses on the use of concurrency to implement naturally concurrent applications. In addition to a tutorial introduction to programming in CML, the book presents three extended examples using CML for practical systems programming: a parallel software build system, a simple concurrent window manager, and an implementation of distributed tuple spaces. This book also illustrates advanced SML programming techniques, and includes a chapter on the implementation of concurrency using features provided by the SML/NJ system. It will be of interest to programmers, students, and professional researchers working in computer language development.

Concurrent Programming in Java. Second Edition: Design Principles and Patterns

Abstract: From the Publisher: The book targets intermediate to advanced programmers interested in mastering the complexities of concurrent programming. Taking a design pattern approach, the book offers standard design techniques for creating and implementing components that solve common concurrent programming challenges. The numerous code examples throughout help clarify the subtleties of the concurrent programming concepts discussed.

An approach to declarative programming based on a rewriting logic

Abstract: We propose an approach to declarative programming which integrates the functional and relational paradigms by taking possibly non-deterministic lazy functions as the fundamental notion. Classical equational logic does not supply a suitable semantics in a natural way. Therefore, we suggest to view programs as theories in a constructor-based conditional rewriting logic. We present proof calculi and a model theory for this logic, and we prove the existence of free term models which provide an adequate intended semantics for programs. We develop a sound and strongly complete lazy narrowing calculus, which is able to support sharing without the technical overhead of graph rewriting and to identify safe cases for eager variable elimination. Moreover, we give some illustrative programming examples, and we discuss the implementability of our approach.

The Haskell School of Expression: Learning Functional Programming through Multimedia

Abstract: From the Publisher: Functional programming is a style of programming that emphasizes the use of functions (in contrast to object-oriented programming, which emphasizes the use of objects). It has become popular in recent years because of its simplicity, conciseness, and clarity. This book teaches functional programming as a way of thinking and problem solving, using Haskell, the most popular purely functional language. Rather than using the conventional (boring) mathematical examples commonly found in other programming language textbooks, the author uses examples drawn from multimedia applications, including graphics, animation, and computer music, thus rewarding the reader with working programs for inherently more interesting applications. Aimed at both beginning and advanced programmers, this tutorial begins with a gentle introduction to functional programming and moves rapidly on to more advanced topics.

The Connectionist Inductive Learning and Logic Programming System

Abstract: This paper presents the Connectionist Inductive Learning and Logic Programming System (C-IL^2P). C-IL^2P is a new massively parallel computational model based on a feedforward Artificial Neural Network that integrates inductive learning from examples and background knowledge, with deductive learning from Logic Programming. Starting with the background knowledge represented by a propositional logic program, a translation algorithm is applied generating a neural network that can be trained with examples. The results obtained with this refined network can be explained by extracting a revised logic program from it. Moreover, the neural network computes the stable model of the logic program inserted in it as background knowledge, or learned with the examples, thus functioning as a parallel system for Logic Programming. We have successfully applied C-IL^2P to two real-world problems of computational biology, specifically DNA sequence analyses. Comparisons with the results obtained by some of the main neural, symbolic, and hybrid inductive learning systems, using the same domain knowledge, show the effectiveness of C-IL^2P.

Generic Programming: An Introduction

Abstract: The development of science proceeds in a cycle of activities, the so-called abstraction-specialisation cycle. Abstraction is the process of seeking patterns or commonalities, which are then classified, often in a formal mathematical framework. In the process of abstraction, we gain greater understanding by eliminating irrelevant detail in order to identify what is essential. The result is a collection of general laws which are then put to use in the second phase of the cycle, the specialisation phase. In the specialisation phase the general laws are instantiated to

A Programming Logic for Sequential Java

Abstract: A Hoare-style programming logic for the sequential kernel of Java is presented. It handles recursive methods, class and interface types, subtyping, inheritance, dynamic and static binding, aliasing via object references, and encapsulation. The logic is proved sound w.r.t. an SOS semantics by embedding both into higher-order logic.

The Problem of Teaching Object-Oriented Programming, Part 1: Languages

Abstract: Object-oriented programming has, in recent years, become the most influential programming paradigm. It is widely used in education and industry, and almost every university teaches object-orientation somewhere in its curriculum. The software community more or less agrees that teaching object-oriented programming is a good thing. It elegantly supports the concepts that we have been trying to teach for many years, such as well structured programming, modularisation and program design. It also supports techniques for approaching problems that have only more recently made their way into the curriculum: programming in teams, maintenance of large systems and software reuse. In short, object-oriented programming seems to be a good tool for teaching those programming methodologies that we consider important.

Computing argumentation in logic programming

Abstract: In recent years, argumentation has been shown to be an appropriate framework in which logic programming with negation as failure as well as other logics for non-monotonic reasoning can be encompassed. Many of the existing semantics for negation as failure in logic programming can be understood in a uniform way using argumentation. Moreover, other logics for non-monotonic reasoning that can also be formulated via argumentation can be given new semantics, by a direct extension of the logic programming semantics. In this paper we develop an abstract computational framework where various argumen-tation semantics can be computed via diierent parametric variations of a simple basic proof theory. This proof theory is given in terms of derivations of trees where each node in a tree contains an argument (or attack) against its corresponding parent node. The proposed proof theory, deened here for the case of logic programming, generalises directly to other logics for non-monotonic reasoning that can also be formalised via argumentation. The abstract proof theory forms the basis for developing concrete top-down proof procedures for query evaluation. These proof procedures are obtained by adopting speciic search strategies and ways of computing attacks in the particular argumentation framework. For logic programming these procedures can be seen as a generalisation of the Eshghi-Kowalski abductive proof procedure that in turn generalises SLDNF. This is an extended and revised version of the earlier paper 46].

The Problem of Teaching Object-Oriented Programming, Part 2: Environments

Abstract: In last month’s edition of JOOP we started a series of columns discussing the problems with teaching object-oriented programming to first year students. We talked about requirements for an object-oriented teaching language and analysed how close different languages come to fulfil these requirements. We also mentioned one important aspect: the importance of the environment. In short: a suitable programming environment is crucial for the success of an introductory course. Of all the problems reported by educators connected to teaching object-orientation, problems with the environment used were the most frequent and the most severe. Because of this importance, we devote this month’s column to the discussion of environments. Again, the context we focus on is the suitability of environments for first-year teaching.

Programming in an Integrated Functional and Logic Language.

Abstract: Escher is a general-purpose, declarative programming language that integrates the best features of both functional and logic programming languages. It has types and modules, higher-order and meta-programming facilities, concurrency, and declarative input/output. The main design aim is to combine in a practical and comprehensive way the best ideas of existing functional and logic languages, such as Haskell and Gödel. In fact, Escher uses the Haskell syntax and is most straightforwardly understood as an extension of Haskell. Consequently, this paper discusses Escher from this perspective. It provides an introduction to the Escher language, concentrating largely on the issue of programming style and the Escher programming idioms not provided by Haskell. Also the extra mechanisms needed to support these idioms are discussed.

The Logic Programming Paradigm

Abstract: debugging [13,14]' or more traditional interactive debuggers [11,20J may be applied. Global Analysis, Partial Specifications, and Assertions 167 started, for example using abstract diagnosis [13,14], in order to detect the cause of the error. It is also possible that a (part of the) assertion cannot be proved nor disproved. In this case some assertions, or part of them, remain in check status, and possibly warning messages are presented to the user. Note that it may also be interesting to implement analysis in a demanddriven way, so that information is inferred only for the program points which include assertions. The advantage of this approach is that it may be more efficient. However, three other considerations should be weighted against this. First, for many properties it is not possible to isolate the analysis of a given program point, and a global fixpoint has to be reached in any case, which requires analyzing at least the whole module involved. Also, the results of analysis are typically useful in other stages of compilation (e.g., to perform program specialization or other optimizations). Finally, in our experience bugs can often be detected by visual inspection of the assertions containing the information inferred by the analyzer, sometimes for program points which are "distant" from the user-provided check assertions. Compile-time checking is discussed further in Section 6. 3 The Assertion Language Assertions may be used in different contexts and for different purposes. In run-time checking, assertions are traditionally used to express conditions which should hold at run-time. A usual example is to check that the value of a variable remains within a given range at a given program point. In declarative debugging [41], assertions have been used in order to replace the oracle by allowing the user expressing properties of the intended behaviour of the program [18,19,6]. Assertions can also be used to express properties about the program to be checked at compile-time. An example of this are type declarations (e.g., [30,42], functional languages, etc.), which have been shown to be useful in debugging. Assertions have also been used to provide information to an optimizer in order to perform additional optimizations during code generation (e.g., [42], which also implements checking). Assertions have also been proposed as a means of providing additional information to the analyzer, which it can use both to increase the precision of the information it infers and/or to perform additional optimizations during code generation [45,43,32,31]. Also, assertions can be used to represent analysis output in source form and for communication between different modules of the compiler which deal with analysis information [8]. The assertion language used in our framework has been designed with the aim of being useful in all the contexts mentioned above. With this objective in mind, we depart from previous proposals in allowing more general properties to be expressed. Each tool in each of the contexts will then use the properties which are relevant to it. Assertions are provided to specify the program points to which the properties are "attached." In this sense they 168 Manuel Hermenegildo, German Puebla, and Francisco Bueno calls qsort(A,B) : list(A). 1. Ai success qsort(A,B) : list(A) => list(B). 1. A2 comp qsort(A,B) : (list(A),var(B» + does_not_fail. 1. A3 qsort([XIL],R) :partition(L,X,Ll,L2), qsort(L2,R2), qsort(Ll,Rl), append(Rl,[XIR2],R). qsort ([] , [] ) . Fig. 2. An example predicate definition with assertions work as schemas. Due to space limitations, we do not present here the complete assertion language, but rather we concentrate on a subset of it which suffices for illustrating the main concepts involved in compile-time and runtime checking of assertions. In particular, we will focus on predicate assertions rather than on program point assertions. Also for brevity, we will use only operational assertions, although the assertion language also includes declarative assertions (inmodel/outmodel). A more detailed description of the assertion language can be found in [36]. Predicate assertions relate properties to the invocations of a predicate. Three kinds of predicate assertions are provided; they relate properties to the execution states at the time of calling the predicate, at the time of its success, and to the whole of its computation. More than one predicate assertion (of the same or different kinds) may be given for the same predicate. In such a case, all of them should hold and composition of predicate assertions should be interpreted as their conjunction. We first illustrate the use of this kind of assertions with an example. Figure 2 presents (part of) a CIAO [7] program which implements the quicksort algorithm for sorting lists in ascending order. The predicate qsort is annotated with predicate assertions which express properties which the user expects to hold for the program.7 Three assertions are given for predicate qsort: Ai, A2, and A3, the meaning of which is explained below. Assertions on Success States. They are similar in nature to the postconditions used in program verification. They can be expressed in our assertion language using the assertion schema' : success Pred => Postcond.' It should be interpreted as "for any call of the form Pred which succeeds, on success Postcond 7 Both for convenience, i.e., so that the assertions concerning a predicate appear near its definition in the program text, and for historical reasons, i.e., mode declarations in Prolog or entry and trust declarations in PLAI [8] we write predicate assertions as directives. Depending on the tool different choices could be implemented, including for example putting assertions in separate files or incremental addition of assertions in an interactive environment. Global Analysis, Partial Specifications, and Assertions 169 should hold." For example, we can use the following assertion in order to require that the output of the procedure qsort for sorting lists be a list: success qsort(A,B) => list(B). Note that, in contrast to other programming paradigms, in (C)LP calls to a predicate may either succeed or fail. The postcondition stated in a success assertion only refers to successful executions. Assertions Restricted to a Subset of the Calls. Sometimes we are interested in properties which refer not to all invocations of a predicate, but rather to a subset of them. With this aim we allow the addition of preconditions (Precond) to predicate assertions as follows: 'Pred : Precond.' For example, success assertions can be restricted and we obtain an assertion of the form ': success Pred : Precond => Postcond,' which should be interpreted as "for any call of the form Pred for which Precond holds, if the call succeeds then on success Postcond should also hold." Note that' : success Pred => Postcond' is equivalent to ': success Pred : true => Postcond.' For example, the assertion A2 in Figure 2 requires that if qsort is called with a list in the first argument position and the call succeeds, then on success the second argument position should also be a list. Assertions on Call States. It is also possible to use assertions to describe properties about the calls for a predicate which may appear during program execution. This is useful for at least two reasons. If we perform goal-dependent analysis, a variation of calls assertions, namely entry assertions (see [8]), may be used for improving analysis information.8 They can also be used to check whether any of the calls for the predicate is not in the expected set of calls (the "inadmissible" calls of [35]). An assertion of the kind ': calls Pred : Cond' should be interpreted as "all calls of the form Pred should satisfy Cond." An example of this kind of assertion is A1 in Figure 2 which expresses that in all calls to predicate qsort the first argument should be a list. Assertions on the Computation of Predicates. Many properties which refer to the computation of the predicate, rather than the input-output behaviour, are not expressible with the assertions presented above. In particular, no property which refers to (a sequence of) intermediate states in the computation of the predicate can be easily expressed using calls and success predicate assertions only. Examples of properties of the computation which we may be interested in are: non-failure, termination, determinacy, non-suspension, non-floundering, etc. In our language this sort of properties are expressed by an assertion of the kind ': comp Pred : Precond + Comp-prop,' which is interpreted as "for any call of the form Pred for which Precond holds, 8 The entry (and trust) declarations are also instrumental in incremental modular analysis. 170 Manuel Hermenegildo, German Puebla, and Francisco Bueno Comp-prop should also hold for the computation of Pred." Again, the field ': Precond' is optional. For example, A3 in Figure 2 requires that all calls to predicate qsort with the first argument being a list and the second a variable do not fail. 4 Defining Properties Whereas each kind of assertion indicates when, i.e., in which states or sequences of states, to check the given properties, the properties themselves define what to check. As mentioned before, properties are used to say things such as "X is a list of integers," "Y is ground," "p(X) does not fail," etc. and in our framework they are logic predicates, in the sense that the evaluation of each property either succeeds or fails. The failure or success of properties typically needs to be determined at the time when the assertions in which they appear are checked. As also mentioned previously, assertions can be checked both at compile-time and at run-time. In order to simplify the discussion, in this section we will concentrate exclusively on run-time checking (the role of properties during compile-time checking will be discussed in Section 6). In order to make it possible to check a

A constructivist approach to object-oriented design and programming

Abstract: Computer science education is greatly affected by the object-oriented approach. This can be seen in the numerous new teachers being attracted to programming languages such as Java. Learning the object-oriented approach is however difficult for novice students, mostly because it requires a new way of thinking about computing and more depth to grasp. Thus, to promote the object-oriented approach at the introductory level, a re-examination of the teaching method is recommended. This article describes a pedagogical framework rooted in the constructivist epistemology for teaching object-oriented design and programming.

Higher-order narrowing with definitional trees

Abstract: Functional logic languages with a sound and complete operational semantics are mainly based on an inference rule called narrowing. Narrowing extends functional evaluation by goal solving capabilities, as in logic programming. Due to the huge search space of simple narrowing, steadily improved narrowing strategies have been developed in the past. Needed narrowing is currently the best narrowing strategy for first-order functional logic programs due to its optimality properties wrt the length of derivations and the number of computed solutions. In this paper, we extend the needed narrowing strategy to higher-order functions and λ-terms as data structures. By the use of definitional trees, our strategy computes only independent solutions. Thus, it is the first calculus for higher-order functional logic programming which provides for such an optimality result. Since we allow higher-order logical variables denoting λ-terms, applications go beyond current functional and logic programming languages. We show soundness and completeness of our strategy with respect to LNT reductions, a particular form of higher-order reductions defined via definitional trees. A general completeness result is only provided for terminating rewrite systems due to the lack of an overall theory of higher-order reduction which is outside the scope of this paper.

Aspect-Oriented Logic Meta Programming

Abstract: We propose to use a logic meta-system as a general framework for aspect-oriented programming. We illustrate our approach with the implementation of a simplified version of the cool aspect language for expressing synchronization of Java programs. Using this case as an example we illustrate the principle of aspect-oriented logic meta programming and how it is useful for implementing weavers on the one hand and on the other hand also allows users of aop to fine-tune, extend and adapt an aspect language to their specific needs.

Prototype-Based Programming: Concepts, Languages and Applications

Abstract: Concepts and History: Classes vs. Prototypes: Some Philosophical and Historical Observations Classifying Prototype-based Programming Languages The Stripetalk Papers: Understandability as a Language Design Issue in Object-Oriented Programming Systems Classes versus Prototypes in Object-Oriented Languages.- Languages: Programming as an Experience: The Inspiration for Self NewtonScript: Prototypes on the Palm The Prototype-Instance Object Systems in Amulet and Garnet Omega: Statically Typed Prototypes. Research and Applications: Self text includes: Smalltalk Using Prototypes for Program Restructuring Prototype-Based Programming for Abstract Program Visualisation Agora: The Simplest MOP in the World - or - The Scheme of Object-Orientation.

Aspect-Oriented Compilers

Abstract: Aspect-oriented programming provides the programmer with means to cross-cut conventional program structures, in particular the class hierarchies of object-oriented programming This paper studies the use of aspect orientation in structuring syntax directed compilers implemented as attribute grammars Specifically, it describes a method for specifying definitions of related attributes as 'aspects' and treating them as first-class objects, that can be stored, manipulated and combined It is hoped that this embedding of an aspect-oriented programming style in Haskell provides a stepping stone towards a more general study of the semantics of aspect-oriented programming

Likelog: a logic programming language for flexible data retrieval

Abstract: Starting from unification based on similarity, a logic programming system, called Likelog, (LIKEness in LOGic) is derived, thorougly relying on similarity. An operational semantics and a fix-point semantics are defined, using an extension principle for fuzzy operators. The two approaches are proved to be related and a fuzzy extension of the Ieast Herbrand model is given. One of the principal feature of such a logic programming system is to allow flexible information retrieval in deductive data bases.

When is a functional program not a functional program

Abstract: In an impure functional language, there are programs whose behaviour is completely functional (in that they behave extensionally on inputs), but the functions they compute cannot be written in the purely functional fragment of the language. That is, the class of programs with functional behaviour is more expressive than the usual class of pure functional programs. In this paper we introduce this extended class of "functional" programs by means of examples in Standard ML, and explore what they might have to offer to programmers and language implementors.After reviewing some theoretical background, we present some examples of functions of the above kind, and discuss how they may be implemented. We then consider two possible programming applications for these functions: the implementation of a search algorithm, and an algorithm for exact real-number integration. We discuss the advantages and limitations of this style of programming relative to other approaches. We also consider the increased scope for compiler optimizations that these functions would offer.

Generic programming, partial evaluation, and a new programming paradigm

Abstract: We describe in this paper a new approach to Generic Programming that combines our integration results with Partial Evaluation methods for adaptation. Our approach supports Partial Evaluation by providing much more information than is usually available, including explicit meta-knowledge about the program fragments and their intended execution environments. We make some ambitious claims here, so we provide some detail about our methods, to justify our interest and expectations. We are not claiming to have solved the problem; only that we think our methods circumvent some of the know difficulties that were previously identified or encountered in approaches to Generic Programming.

Distributed Programming in a Multi-Paradigm Declarative Language

Abstract: Curry is a multi-paradigm declarative language covering functional, logic, and concurrent programming paradigms Curry’s operational semantics is based on lazy reduction of expressions extended by a possibly non-deterministic binding of free variables occurring in expressions Moreover, constraints can be executed concurrently which provides for concurrent computation threads that are synchronized on logical variables In this paper, we extend Curry’s basic computational model by a few primitives to support distributed applications where a dynamically changing number of different program units must be coordinated We develop these primitives as a special case of the existing basic model so that the new primitives interact smoothly with the existing features for search and concurrent computations Moreover, programs with local concurrency can be easily transformed into distributed applications This supports a simple development of distributed systems that are executable on local networks as well as on the Internet In particular, sending partially instantiated messages containing logical variables is quite useful to implement reply messages We demonstrate the power of these primitives by various programming examples

Introduction to Computing Systems: From Bits and Gates to C and Beyond

Abstract: From the Publisher: The reason most students do not understand their first programming language is because they are forced to memorize technical details. They do not understand the basic underpinnings. This book is based on the premise that starting with a high level programming language has its shortcomings This premise lead to Patt/Patel's "bottom-up approach" found in "Introduction To Computing. " This text covers (in order) a switch level abstraction of a MOS Transistor,Logic Gates,latches,logic structures (MUX,Decoder,Adder,gated latches),finally culminating in an implementation of memory. From there,the book moves on to the Von Neumann model of execution,then a simple computer (the LC-2),machine language programming and then assembly language programming of the LC-2,the high level language C,recursion,and finally elementary data structures. The book establishes a foundation that can easily be built upon

Declarative Aspect-Oriented Programming.

Abstract: Aspect-oriented programming addresses the problem that the implementation of some properties such as error handling and optimization tends to cross-cut the basic functionality. To overcome that problem special languages are used to specify such properties—the so-called aspects—in isolation. The software application is obtained by weaving the aspect code and the implementation of properties corresponding to basic functionality—the so-called components. This paper investigates the suitability of functional meta-programs to specify aspects and to perform weaving. The proposal focuses on the declarative paradigm (logic programming, attribute grammars, natural semantics, constructive algebraic specification etc.) as far as components are concerned, whereas aspects are represented by program transformations. Weaving is regarded as a program composition returning a combination of the components satisfying all the aspects. The computational behaviour of the components is preserved during weaving. The proposal improves reusability of declarative programs. The approach is generic in the sense that it is applicable to several representatives of the declarative paradigm. Several roles of aspect code are defined and analysed.

Disjunctive logic programs with inheritance

Abstract: The paper proposes a new knowledge representation language, called DLP<, which extends disjunctive logic programming (with strong negation) by inheritance. The addition of inheritance enhances the knowledge modeling features of the language providing a natural representation of default reasoning with exceptions. A declarative model-theoretic semantics of DLP< is provided, which is shown to generalize the Answer Set Semantics of disjunctive logic programs. The knowledge modeling features of the language are illustrated by encoding classical nonmonotonic problems in DLP<. The complexity of DLP< is analyzed, proving that inheritance does not cause any computational overhead, as reasoning in DLP< has exactly the same complexity as reasoning in disjunctive logic programming. This is confirmed by the existence of an efficient translation from DLP< to plain disjunctive logic programming. Using this translation, an advanced KR system supporting the DLP< language has been implemented on top of the DLV system and has subsequently been integrated into DLV.

Formal validation of PLC programs: A survey

Abstract: The aim of this paper is to give an overview of the validation methods for IEC 61131-3 programming languages for programmable logic controllers. More precisely we are focussing on the SFC structuring language and on the LD programming language. The SFC and LD validation methods are detailed after a short presentation of the usual formal methods and of the IEC 61131-3 standard.