79 citations found. Retrieving documents...
Y. Deville. Logic Programming: Systematic Program Development. Addison-Wesley, 1990.

 Home/Search   Document Not in Database   Summary   Related Articles   Check  

This paper is cited in the following contexts:

First 50 documents  Next 50

Unknown -   (Correct)

....work. A more detailed comparison with the work on de nite programs can be found in [Dra99] Due to our approach to speci cations, we do not need any explicit notion of precondition, type information, or domain of a procedure. Such notions are used in most other approaches [BC89,Apt97,PR99,Dev90] to deal with ill typed atoms, for which the behaviour of the program is of no interest. Our approach is related to a 3 valued approach to de nite programs [Nai00] We however avoid any use of 3 valued logic. Nai96] advocated declarative view for a class of program properties. A completeness ....

....expect that reasoning in Section 3. 2 can be generalized to this case thus showing that the operational method is not stronger (as far as properties of program answers are concerned) Our approach to normal programs considers their 3 valued semantics, which is more precise than 2 valued, used in [Dev90,Apt93,PR99] Further comparisons are needed with [Dev90] and with completeness realated reasoning in [PR99] An important approach to proving properties of normal programs is proposed by St ark [St a97] It deals with normal programs, executed under Prolog selection rule. A tool to mechanically ....

[Article contains additional citation context not shown here]

Y. Deville. Logic Programming: Systematic Program Development. AddisonWesley, 1990.


Building a Knowledge Base: An Example - Gelfond, Gabaldon (1999)   (Correct)

....is to demonstrate, by way of example, how this can be achieved. Finally, we want to mention that in this paper we are mainly interested in the first two stages of the development process. In this sense our approach is complementary to the work on program development in Prolog (see, for instance, [14]) See, however, proposition 13. The paper is organized as follows. In the next two sections we review the answer set semantics of logic programs and the notions of f specification and lpfunction. In the next section we give a first example of applying our methodology to solving a knowledge ....

Y. Deville, Logic Programming: Systematic Program Development (Addison-Wesley, Reading, MA, 1990).


Derivation of Efficient Logic Programs by.. - Pettorossi, Proietti, .. (2001)   (Correct)

....because there exists a value for X, namely 1, which is syntactically di erent from 0. However, p(1) does not succeed in P , because X and 0 are uni able terms. 2. 4 Deterministic Programs Various notions of determinism have been proposed for logic programs in the literature (see, for instance, [10, 18, 30, 42]) They capture various properties such as: the program succeeds at most once , or the program succeeds exactly once , or the program will never backtrack to nd alternative solutions . Let us now present the de nition of deterministic program used in this paper. This de nition is based on ....

....disequation. 5 Program Transformations based on Modes Modes provide information about the directionality of predicates, by specifying whether an argument should be used as input or output (see, for instance, 31, 48] Mode information is very useful for specifying and verifying logic programs [2, 10] and it is used in existing compilers, such as Ciao and Mercury, to generate very ecient code [19, 44] Mode information has also been used in the context of program transformation to provide sucient conditions which ensure that reorderings of atoms in the body of a clause preserve program ....

[Article contains additional citation context not shown here]

Y. Deville. Logic Programming: Systematic Program Development. Addison-Wesley, 1990.


Translating Refined Logic Programs to Mercury - Colvin, Hayest, Hemer, Strooper   (Correct)

.... then a separate process must be undertaken to manipulate the program into executable form (cf. logic program transformation [Pettorossi and Proietti, 2000] Our approach of separating translation from the task of deriving a logic description of the problem is similar to the approach of Deville [Deville, 1990]. Deville includes transformation laws for improving the efficiency of the final program, which we may con sider for the translator. 5.2 Future work ff the refiner wishes to derive a Mercury procedure from a specification, the final program must include the types of the parameters in order to ....

Deville, Y. (1990). Logic Program- ming: Systematic Program Development. International series in logic programming. AddisonWesley.


Building a Knowledge Base: An Example - Gelfond, Gabaldon (2000)   (Correct)

....is to demonstrate, by way of example, how this can be achieved. Finally, we want to mention that in this paper we are mainly interested in the first two stages of the development process. In this sense our approach is complementary to the work on program development in Prolog (see for instance [12]) See however Proposition 13) The paper is organized as follows. In the next two sections we review the answer set semantics of logic programs and the notions of f specification and lp function. In the next section we give a first example of applying our methodology to solving a knowledge ....

Y. Deville. Logic Programming: systematic program development, Clark, K., series editor, Addison-Wesley Publishing Co., 1990.


Proving Correctness and Completeness of Normal Programs - a.. - Drabent (2001)   (Correct)

....method of Deransart [Der93, Section 4] BM97, Section 4] for proving de nite program correctness. It can be seen as a re nement of the natural method of Section 3.1, decomposing the implications to be proved into smaller ones. An important work on constructing correct logic programs is [Dev90] Our approach to speci cations is related to a three valued approach to the semantics of de nite programs [Nai00] We however avoid any explicit use of 3valued logic. Nai96] advocated declarative view for a class of program properties. A method for proving completeness similar to ours was ....

Y. Deville. Logic Programming: Systematic Program Development. AddisonWesley, 1990.


Opportunistic Logic Program Analysis and Optimisation.. - Vasconcelos, Fuchs (1995)   (1 citation)  (Correct)

....A n symbols stand for possibly empty sequences of arguments; the G m symbols, in their turn, represent possibly empty sequences of subgoals. The schema above represents those programs whose first argument is a list and all its elements are recursively manipulated. 1 We shall employ Deville s [Deville 90] definition of a logic procedure or simply procedure as the non empty sequence of program clauses with the same predicate p n (predicate symbol p with number of arguments n) in the head of each of these clauses. 2 Gegg Harrison s schema language employs different symbols though, with Prolog ....

Y. Deville, Logic Programming: Systematic Program Development, Addison-Wesley Publishing Company, 1990.


Derivation of Efficient Logic Programs by.. - Pettorossi, Proietti, .. (2002)   (Correct)

....particular, if the specialized programs are to be run by a standard Prolog system, we may: i) reorder the clauses so that unit clauses appear before non unit clauses, and (ii) remove disequations by introducing cuts instead. For a systematic treatment of cut introduction, we refer the reader to [7]. As an example we now show the program obtained from Match Pos s of Example 6.1 after the above post processing transformations have been performed. Program Match Pos cut (specialized, with cuts) sp match pos(S; N) new1(S; N) new1( ajS] M) new2(S; M) new1( CjS] s(N) new1(S; N) ....

Y. Deville. Logic Programming: Systematic Program Development. Addison-Wesley, 1990.


Program Derivation = Rules + Strategies - Pettorossi, Proietti (2001)   (Correct)

....As we will illustrate in this chapter, our motto also indicates a way of understanding the relationship among various techniques for program development such as program synthesis, program reuse, and program veri cation. Some of these techniques based on rules and strategies, are described in [19,20,33,52]. The main objective of this chapter is to provide a uni ed view of: i) program transformation, ii) program synthesis, and (iii) program veri cation as deductive activities based on the unfolding folding transformation rules and strategies. We consider the class of logic programs with locally ....

Y. Deville. Logic Programming: Systematic Program Development. AddisonWesley, 1990.


Assessment of some issues in CL-theory and program development - Danny De Schreye   (Correct)

....into account) in the development of the programs. Some people have tried to bridge the gap between these two views by promoting program synthesis and transformation as a means to derive efficient programs from purely declarative specifications. Although this work has had some successes (see e.g. [5,6]) it is commonly believed that optimally efficient algorithms cannot be derived automatically from specifications. Note that the KIDS system ( 23] is not a counter example to this statement, since this system requires interaction with the programmer. Turning back to the aspect of having a ....

Y. Deville. Logic Programming: Systematic Program Development. AddisonWesley, 1990.


Logic Program Synthesis via Proof Planning using Clam - Lacey (1999)   (Correct)

....be made into the prolog program: member(X,L) L= L1 L2] X=L1. member(X,L) L= L1 L2] member(X,L2) The representation contains no information regarding control or termination. Information regarding the transformation from a horn program to an executable Prolog program can be found in [Deville 91] 19 4.1.1 Parameterized Synthesis Parameterized synthesis allows a much more exible representation for the syntax of speci cation. It adds conditions to the synthesis of programs. So a speci cation is of the form: 8x: cond(x) 8y: prog(x; y) spec(x; y) where cond(x) is the condition ....

Y. Deville. Logic Programming: Systematic Program Development. Addison-Wesley, 1991. 68


A Declarative Semantics for Logic Program Refinement - Hayes, Nickson, Strooper.. (2000)   (Correct)

....calculus [CHNS97] However, this tool is based around the semantics presented in [HNS97] We are currently working on tool support for the re nement calculus based on the new semantics. Our goal of systematically developing logic programs from speci cations also underlies the work of Deville [Dev90]. However, the main di erence is that Deville s approach to program development is mostly informal, whereas our approach is fully formal. A second distinction is that Deville s approach concentrates on the development of individual procedures. By using a wide spectrum language, our approach blurs ....

Yves Deville. Logic Programming: Systematic Program Development. AddisonWesley, 1990.


Automatic Derivation of Logic Programs by Transformation - Pettorossi, Proietti (2000)   (Correct)

....an overview of some transformation strategies which have been proposed in the literature. They are used, in particular, for solving one of the crucial problems of the transformation methodology, that is, the use of the de nition rule for the introduction of the so called eureka predicates. In [58, 67, 113, 117, 118] one can nd treatments of the transformation strategies both for functional and logic programs. In order to simplify our presentation, sometimes we will not mention the use of the rearrangement rule R6 and the subsumption rule R7. Since these rules preserve the least Herbrand model semantics, we ....

....derivation by looking for a program in which one avoids the evaluation of the goal gen(Xs ; N; Q; Ys) in clause 13, when the body of clause 12 fails after the evaluation of gen(Xs ; N;X;Ys) with Ys being an unbound variable. This can be done by the application of the so called clause fusion [54, 58]. This technique can be mimicked by applying our transformation rules as follows. We rst perform two equality introduction steps followed by a goal rearrangement step and we transform clauses 12 and 13 into: 14 gen( XjXs ] P; Q; Zs) gen(Xs; N; Q; Ys) max (N; X;P ) Q=X; Zs =Ys 15 gen( XjXs ....

[Article contains additional citation context not shown here]

Y. Deville. Logic Programming: Systematic Program Development. Addison-Wesley, 1990.


Rules and Strategies for Transforming Functional and Logic.. - Pettorossi, Proietti (1996)   (51 citations)  (Correct)

.... clauses: 7:18 new1( H; KjT ] P; N) new1( KjT ] P1; N1) p(K; H;P; N; P1;N1) 7:19 p(H; K; H jP ] N; P; N1) plus(K; 1; H) not div any(H; P ) plus(N1; 1; N) 7:20 p(H; K; P; N;P; N) plus(K; 1; H) div some(H; P ) This transformation is sometimes called clause fusion [Debray Warren 88, Deville 90] and its correctness is ensured by the fact that clauses 7.15 and 7.16 can be obtained by unfolding p in clause 7.18 using clauses 7.19 and 7.20. The derived program consisting of clauses 7.17, 7.14, 7.18, 7.19, and 7.20, is more efficient than the initial program because it avoids the visit of ....

....88, Galmiche 91, Sintzoff et al. 89] where a program can be derived from the constructive proof of the existence of an element in a suitable domain type. The transformational methods for developing programs are also closely related to methods for program construction (see, for instance, Deville 90, Sterling Kirschenbaum 93] where complex programs are developed by enhancing and composing together simpler programs. However, the basic ideas and objectives of program construction are different from those of program transformation. In particular, the starting point of the methods for program ....

Deville, Y.: Logic Programming: Systematic Program Development. Addison-Wesley (1990)


Declarative Development of Abstract Machines - A Case Study in.. - Degerstedt (1995)   (Correct)

....give any additional support in comparison with methods based on computational correctness at what level of design this happens is still an open question. The suggested approach is somewhat different in spirit than, for instance, Deville s general method for declarative programming development [8]. Deville suggests to use (the Herbrand fragment of) first order logic for representation of the logical descriptions (lds) consisting of inductively defined predicates, which he employs during the design phase. The design method consists of folding and unfolding transformations in which explicit ....

Deville, Y. Logic Programming -- Systematic Program Development. Addison-Wesley, 1990.


Refining Specifications to Logic Programs - Hayes, Nickson, Strooper (1996)   (Correct)

....is the use of specifications involving assertions, types, and invariants. This type of specification allows refinements to be proved correct with respect to the context in which they appear. To our knowledge, such refinements in context are novel in the logic programming community. Deville [5] introduces a systematic program development method for Prolog that incorporates assertions and types similar to ours. The main difference is that Deville s approach to program development is mostly informal, whereas our approach is fully formal. A second distinction is that Deville s approach ....

Yves Deville. Logic Programming: Systematic Program Development. Addison-Wesley, 1990.


It Is Declarative - On Reasoning About LOGIC PROGRAMS - Drabent   (Correct)

....[Sta97] on proving properties of Prolog programs. It considers programs with negation and contains an implementation of a theorem prover checker. It deals with a broader class of properties than our work, for instance program termination. An important work on constructing correct logic programs is [Dev90]. The purpose of this paper is different; we want to recall a simple and basic method and show that it is at least as useful as the operational one, for a wide range of purposes. Also Naish [Nai96] advocates using the declarative semantics, instead of operational, in reasoning about logic ....

Y. Deville. Logic Programming: Systematic Program Development. Addison-Wesley, 1990.


Applications of Logic Programming in Software Engineering - Ciancarini, Levi (1995)   (Correct)

....written in plain English. 4 However, a formal specification language should exhibit a clear syntax and formal semantics, and a programming logic able to support reasoning on specifications [199] Being based on logic, Prolog allows both writing declarative specifications and reasoning about them [101, 102, 103, 52]. Example: A classic example of Prolog specification is the following [102] sort(X,Y) permutation(X,Y) ordered(Y) This example specifies the sort relationship: argument Y is a sorted version of argument X if Y is a permutation of X and Y is ordered . The specifier should now develop the ....

....of view of efficiency, the specification of sorting given above is not satisfactory, being based on the generate and test strategy. However, such a specification is a good starting point for developing more efficient programs that exhibit the same abstract properties of the specification. The book [52] is entirely devoted to the development of a formalized programming method that includes a logic to reason on Prolog programs. 2 An important aspect of any formal method is the support offered for refinement of specifications, i.e. for obtaining an implementation which correctly implements the ....

[Article contains additional citation context not shown here]

Y. Deville. Logic Programming: Systematic Program Development. Addison-Wesley, 1990.


Verification of Logic Programs - Pedreschi, Ruggieri (1997)   (1 citation)  (Correct)

....Noy e [28] survey environments for dynamic analysis and debugging. Crnogorac et al. 23] compare 1 some occur check analysis methods. Also, Deransart [24] discusses and compares various verification approaches. Apt s book [7] collects several results on verification of Prolog programs. Deville [26] proposes an approach for systematically deriving (terminating) programs from specifications provided in a Clark s completion like format. It is apparent in the above references that the state of the art in this area is that of a wide collection of separated methods and techniques, whose common ....

.... reference to the procedural interpretation of logic programming [34, 7] The notions of weak partial and partial correctness compare with the notions of correctness and completeness, respectively, used by Deransart [24] Yet other different terminologies are used by other authors, such as Deville [26], to refer to similar notions. As an example, the APPEND program is intuitively totally correct w.r.t. P re; P ost) where P re = f append(xs, ys, zs) j xs; ys are lists g P ost = f append(xs, ys, zs) j zs = xs ys g: where is the list concatenation operator. In the next section we introduce ....

Y. Deville. Logic Programming: Systematic Program Development. Addison-Wesley, 1990.


A Logical Framework for Programming Paradigm Amalgamation - Habra, al. (1994)   (Correct)

....concluding remarks. 1 2 Syntax Roughly, well formed formulae of the language are typed first order logic formulae having a particular form of relation definition. The form corresponds to the completion of Prolog program introduced by Clark [Llo87] and to the logical descriptions introduced by [Dev90] but without explicit compound terms. 2.1 Definition ffl Let S denotes a set of sorts. An S sorted signature ( Pi; Sigma) consists of a set of predicate names Pi = fp, q, r, g and a set of function names Sigma = ff ,g,h, g where each predicate (resp. function) name is equipped with ....

....be made continuous by different means: ffl A given program construction methodology may ensure that the produced program P corresponds to an operator XB which reaches its fixpoint at the first ordinal . Such methodology has been developed for the case of Logic Programming in the project Folon [Dev90, HLC92, DBLC93]; one of our future goals is to generalize this methodology so as to deal with the general language developed here. ffl One can consider restrictions on the language syntax (e.g. to positive literals only) or restrictions on the interpretation domains (e.g. to finite domains only) Since the ....

Y. Deville. Logic Programming: Systematic Program Development. International Series in Logic Programming. Addison-Wesley, Wokingham, United Kingdom, 1990. 12


Refining Logic Programs using Types and Invariants - Colvin, Hayes, Strooper (1999)   (Correct)

....to certain types, though the procedure itself does not necessarily enforce these restrictions. Hence it is possible for a procedure to return incorrect results if its parameters are incorrectly typed. Therefore, in the specifications of procedures, it is essential to include typing information [6]. Furthermore, the types of variables provide useful context information for refinement of specifications to code. This paper looks at the role of types, and their generalisation invariants, in the logic programming refinement calculus. Types are handled as predicates, which avoids introducing ....

....We also desire that the invariant can be eliminated from the program if no longer required, which we call discharging the invariant . Related work in this field includes extensive work on the role of types in logic programming, which we adapt for the logic programming refinement calculus, e.g. [6, 12]. There is also considerable work on type languages for logic programs, allowing generic types and decidability of the type system [13] However we do not introduce a new notation for types in the logic refinement calculus, instead defining types by predicates describing a syntactic form in the ....

[Article contains additional citation context not shown here]

Yves Deville. Logic Programming: Systematic Program Development. International series in logic programming. Addison-Wesley, 1990.


A Unified View of Program Schemas and Proof Methods - Flener, Richardson   (Correct)

No context found.

Y. Deville. Logic Programming: Systematic Program Development. Addison-Wesley, 1990.


Improving Prolog Programs: Refactoring for Prolog - Schrijvers, Serebrenik   (Correct)

No context found.

Y. Deville. Logic Programming: Systematic program development. Addison-Wesley, 1990.


Generalized Generalization Generalizers (Extended Abstract) - Büyükyildiz, Flener   (Correct)

No context found.

Y. Deville. Logic Programming: Systematic Program Development. Addison Wesley, 1990.


Program Schemas as Steadfast Programs and their Usage in.. - Flener (1997)   (Correct)

No context found.

Y. Deville. Logic Programming: Systematic Program Development . Addison-Wesley, 1990.

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC