Lee Naish. Types and the intended meaning of logic programs. In Frank Pfenning, editor, Types in logic programming, pages 189--216. MIT Press, Cambridge, Massachusetts, 1992.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....other type. Because all the variables in T rans(P) actually come from , all the variables in have the first type. It has been argued that logic programs often make implicit assumptions about types and that a logic program only satisfies its intended meaning if type information is added to it [58]. We think that typing is potentially useful in LP based authorization languages. In authorization, there are different types of entities, e.g. subjects, objects, groups, roles, etc. Most predicates should only take arguments of certain types. One can add typing to DL. Actually, typing is ....

Lee Naish, "Types and the Intended Meaning of Logic Programs," in [63], pp. 189--216, 1992.

....in have the first type. This fact will be crucial to the tractability result of D1LP inferencing in Section 5.2. It has been argued that logic programs often make implicit assumptions about types and that a logic program only satisfies its intended meaning if type information is added to it [37]. We observe that, in authorization, there are conceptually di#erent types of entities, e.g. subjects, objects, groups, roles, etc. Most predicates conceptually should only take arguments of certain types. One might thus add typing directly and explicitly to DL and its syntax. Actually, a degree ....

Lee Naish. Types and the intended meaning of logic programs. In F. Pfenning, editor, Types in Logic Programming, pages 189--216. The MIT Press, 1992.

....other type. Because all the variables in Trans(P) actually come from all the variables in have the first type. It has been argued that logic programs often make implicit assumptions about types and that a logic program only satisfies its intended meaning if type information is added to it [37]. We think that typing is potentially useful in LP based authorization languages. In authorization, there are di#erent types of entities, e.g. subjects, objects, groups, roles, etc. Most predicates should only take arguments of certain types. One can add typing to DL. Actually, typing is ....

Lee Naish. Types and the intended meaning of logic programs. In Types in Logic Programming, pages 189--216. The MIT Press, 1992.

....as their basis, logic programming languages are based on the untyped theory of predicate calculus. As a consequence, logic programming languages have traditionally been untyped. Nonetheless, it has been shown that types play an important role in the programmer s intended meaning of a logic program [74]. Early work on types in logic programming concentrated on descriptive type systems [11, 68, 106, 112] A descriptive type system is one which does not seek to distinguish between well typed and ill typed programs; instead, it seeks to simply approximate the structure of a program for use by an ....

Lee Naish. Types and the intended meaning of logic programs. In Frank Pfenning, editor, Types in Logic Programming, chapter 6, pages 189-216. MIT Press, Cambridge, Massachusetts, 1992.

....logic. In addition, it is important that the program contain su#cient information for precise analysis. To this end, declarations that supplement the program clauses are very important because they restrict (in a well defined way) the possible set of intended interpretations of a predicate (see [69, 72]) and therefore let program analyses avoid having to make unnecessary generalizations. The Mercury group at the University of Melbourne have developed a logic programming language (Mercury [98] which aims to satisfy all these requirements. We use the basic Mercury language as the foundation on ....

Lee Naish. Types and the intended meaning of logic programs. In Frank Pfenning, editor, Types in Logic Programming, pages 189--216. MIT Press, Cambridge, Massachusetts, 1992.

....type. Because all the variables in T rans(P) actually come from P , all the variables in LO P have the first type. It has been argued that logic programs often make implicit assumptions about types and that a logic program only satisfies its intended meaning if type information is added to it [58]. We think that typing is potentially useful in LP based authorization languages. In authorization, there are different types of entities, e.g. subjects, objects, groups, roles, etc. Most predicates should only take arguments of certain types. One can add typing to DL. Actually, typing is ....

Lee Naish, "Types and the Intended Meaning of Logic Programs," in [63], pp. 189--216, 1992.

.... and verification of logic programs has also been noted by several authors [19] For example, Naish notes that while most specifications of logic programs do take types into account, these types are often ignored in the corresponding Prolog programs, which may lead to incorrect answers [16]. He defines when a program is type correct, which ensures that all well typed answers returned by such programs are correct. He also uses this notion of type correctness to compare the verification of logic programs with that of imperative programs [17] Apt proposes a framework for logic program ....

L. Naish. Types and the intended meaning of logic programs. In F. Pfenning, editor, Types in Logic Programming, pages 189--216. MIT Press, 1992.

....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 ....

....have been diminished. 5 Deriving Type Safe implementations Invariants can be used to turn a type unsafe program into a type safe program. By a type unsafe program we refer to a program that does not respect the types it was intended for. This problem has been addressed in the literature, e.g. [6, 12]. We apply some of the techniques presented therein in the context of the logic programming refinement calculus. We return to the example of append given in Sect. 3. It defines the relation between three lists, where the first two concatenated are the same as the third. We define it in the ....

L. Naish. Types and the Intended Meaning of Logic Programs, pages 189--216. MIT Press, 1992. In [13].

....mentioned was assigning of types. Type information can be seen as the bridging gap between the minimal Herbrand model (set of logical consequences) and the intended interpretation of a logic program. Such mismatches between semantics of logic programs and their specifications are addressed in [Nai92]. Thus studying how programs are derived and verified, rather than just studying programs themselves, is an alternative approach to uncovering semantics. There exist typed logic programming languages. One such language is Godel, see [PHJL94] as a reference. Programs written in these languages ....

L.Naish. Types And The Intended Meaning Of Logic Programs, In proceedings Types In Logic Programming, pages 189-216, Edited by F.Pfenning, 1992.

....of reasoning on call patterns with respect to the leftmost selection rule. Naish [45] discusses the notion of types as supersets of the least Herbrand model in the sense of (5) by arguing that purely declarative information can actually express the essence of types and modes. He proposes [43, 45] a de nition of declarative typing of programs and applies it to program veri cation and type checking. The resulting declarative proof method is more general than relation but still incomplete. Partial Correctness Among the cited approaches to weak partial correctness, only Malfon [42] shows ....

L. Naish. Types and the Intended Meaning of Logic Programs. In F. Pfenning, editor, Types in Logic Programming, pages 189-216. MIT Press, Cambridge, Massachussets, 1992. 46

....are represented by the constants 0, s(0) s(s(0) and so on. However, there are queries like sum (a; s(0) s(a) which succeed even if some arguments are not numerals. In order to avoid such wrong solutions, one can make use of type checking predicates defined by additional Prolog procedures [17 19]. Our specialisation can be used to solve this problem by restricting the program to a suitable context of application that is expressed in the form of a call post specification. Similarly to classical pre post specifications, a call post specification consists of two parts, a call condition and a ....

Lee Naish. Types and the intended meaning of logic programs. In Frank Pfenning, editor, Types in logic programming, pages 189--216. MIT Press, Cambridge, Massachusetts, 1992.

....These properties may not be fulfilled within untyped framework. Usually the programmer is required to provide types for function symbols and or for predicates. Prescriptive typing is sometimes considered as bridging a gap between the intended semantics and the semantics of the program at hand [Nai92]. This approach is a basis of a few programming languages (e.g. TypedProlog [LR91] Godel [HL94] Mercury [SHC96] The descriptive typing perspective brings us to types as over approximations of program semantics (e.g. the least Herbrand model, s semantics or some operational semantics) This ....

L. Naish. Types and the Intended Meaning of Logic Programs. In F. Pfenning, editor, Types in Logic Programming, pages 189--216. MIT Press, 1992.

....hence less precise) 7.3 Applications The main purpose of this paper is not to describe applications of regular approximations, of which there are many. Type inference and related debugging applications are discussed in [21] 31] and elsewhere. These applications are well presented by Naish [24]. Regular approximation can be combined with the declaration of intended types (stated as regular programs) and program errors detected. The combination of regular approximation with partial evaluation was developed by us in [13] Deletion of useless clauses, detected by a regular approximation, ....

L. Naish. Types and the intended meanings of logic programs. Technical Report, University of Melbourne, Department of Computer Science, 1990.

....so far. Motivated by the above considerations, in this paper we investigate the notion of call correctness for logic programs from a declarative point of view. It allows us to reason on properties of call patterns such as mode and type consistency with respect to a given specification (see [3, 21, 22, 23]) The abstract interpretation technique can be applied to realize practical frameworks for the analysis or verification of the programs [12, 10] More precisely, we first introduce the notion of specialisable call correct (s.c.c. in short) program with respect to a given pre call post ....

Lee Naish. Types and the intended meaning of logic programs. In Frank Pfenning, editor, Types in logic programming, pages 189--216. MIT Press, Cambridge, Massachusetts, 1992.

.... = integer Phi integer Phi integer = integer : ffl type( 0; s(0) list Phi type( s(0) list Phi list Phi type( list Phi list Phi list = list : A well known but often overlooked particularity of logic programs is that their formal semantics often include unintended objects [25]. Consider again the append relation of Example 1 which is intended to describe a relation on lists. We should not forget that the minimal model of this program contains also atoms of the form append( s(0) s(0) and append( 0] s(0) 0js(0) in which some of the arguments are not proper ....

L. Naish. Types and the intended meaning of logic programs. In F. Pfenning, editor, Types in logic programming, pages 189--216. MIT Press, Cambridge, Massachusetts, 1992.

....solutions. This need has arisen mainly in the context of program development, where the detection of such a clause could indicate a bug, since that clause contributes nothing to the program s computation. Such a clause might be considered badly typed . Related topics are discussed in [17] 29] [19] and [30] Normally a programmer would try not to write useless clauses and so their detection is regarded as debugging. However useless clauses arise more frequently in programs that are generated by transforming some other program. In such cases removal of useless clauses is an important part of ....

L. Naish. Types and the intended meaning of logic programs. Technical report, University of Melbourne, 1990.

....We briefly discuss the two representations in the following sections. 2.1. 1 Non Ground Representation The non ground representation, where object level variables are represented by meta level variables at the meta level, was the first representation used for meta programming in logic programming [51, 99, 22, 79]. The so called vanilla interpreters were then developed to demonstrate the power and usefulness of the meta programming approach. Certain meta logical predicates, such as var, however presented semantic problems which made it impossible to give declarative semantics to these predicates. This ....

....Normally a programmer would try not to write a program containing useless clauses, but if such useless clauses exist, it could indicate a bug, since these clauses contribute nothing to successful computations. Such clauses might also be considered badly typed . Related topics are discussed in [79, 71, 110, 111]. Useless clauses arise more frequently in programs generated by transformation systems. In the previous chapter our aim was to transform a program into an equivalent program, but with the different instances of inference rules separated out into different clauses. If this is not done, one ....

L. Naish. Types and the intended meaning of logic programs. Technical report, University of Melbourne, 1990.

....are represented by the constants 0, s(0) s(s(0) and so on. However, there are queries like sum (a; s(0) s(a) which succeed even if some arguments are not numerals. In order to avoid such wrong solutions, one can make use of type checking predicates defined by additional Prolog procedures [18 20]. A more flexible solution consists of augmenting the program with so called delay declarations [17, 24] specifying the conditions under which queries are allowed to be evaluated. Our specialisation can be used to solve this problem by restricting the program to a suitable context of application ....

L. Naish. Types and the intended meaning of logic programs. In Frank Pfenning, editor, Types in logic programming, pages 189--216. The MIT Press, Cambridge, 1992.

....This application has occurred mainly in the context of program development, where the detection of such a clause could indicate a bug, since that clause contributes nothing to the program s computation. Such a clause might be considered badlytyped . Related topics are discussed in [16] 26] [19], 27] Definition 4.1 useless clause Let P be a normal program and let C 2 P be a clause. Then C is useless if for all goals G, C is not used in any refutation of P [ fGg. A stronger notion of uselessness is obtained by considering particular computations. Definition 4.2 useless clause with ....

L. Naish. Types and the Intended Meaning of Logic Programs. Technical Report, University of Melbourne, 1990.

....to forward reasoning. The use of forward reasoning to write and verify Prolog programs has been largely ignored. However, work on the relationship between specifications, logic programs and type information suggests that often consequence verification cannot be directly applied to Prolog programs [Nai90]. The problem is that many Prolog programs make implicit assumptions 2 about the types of their arguments. For example, the intended semantics of append is that all arguments should be lists, but the with the normal definition, calls can succeed with non lists. The base case of append is ....

....defining append, it is assumed that top level calls will be well typed, and this is maintained as an invariant in subsequent recursive calls. More generally, there can be arbitrary assumptions about calls. Maintaining these assumptions as invariants requires forward reasoning. The type scheme of [Nai90] allows very general assumptions to be expressed explicitly by using type declarations. The assumptions do not cause incorrect answers as long as the program is type correct. Using this scheme, verification of Prolog programs can be done in two parts. First, we use forward reasoning to show that ....

[Article contains additional citation context not shown here]

L. Naish. Types and the intended meaning of logic programs. Technical Report 90/4, Department of Computer Science, University of Melbourne, Melbourne, Australia, February 1990. To appear in Types in Logic Programming, MIT Press.

....However, strong type checking also rejects many programs which would otherwise work correctly. Programmers who are used to the flexibility of untyped languages such as Prolog often object to such restrictions on their programming style. 2. 3 More flexible typed semantics The type scheme of [Nai92] was designed to solve the semantic difficulties discussed so far, while restricting correct programs as little as possible. Types in this scheme can be defined by arbitrary Horn clause programs. This allows the assumptions of predicates such as merge to be expressed by types. The intended ....

....for this paper, we do not rely on any particular definition of inadmissibility here. We simply assume that the programmer has some notion of (in)admissibility and that admissibility is closed under instantiation. If inadmissibility is identified with ill typedness (as suggested in [Per86] and [Nai92]) then the second class of bugs correspond to clauses which are not type correct. However, this definition of inadmissibility does not lead to ideal behaviour of debuggers [Nai97b] and does not quite capture the intentions of programmers. As well as considering types, programmers consider modes. A ....

[Article contains additional citation context not shown here]

Lee Naish. Types and the intended meaning of logic programs. In Frank Pfenning, editor, Types in logic programming, pages 189--216. MIT Press, Cambridge, Massachusetts, 1992.

....views which support our proposition. We then present an expressive polymorphic mode system which has a very simple declarative semantics. Finally, mode checking and inference are briefly discussed. 2 Background The need for types In this section we briefly summarise our views on types [Nai92] Types are essential to logic programming because most logic programs do not contain sufficient information about the programmer s intended interpretation. For example, in the intended interpretation of append all arguments are lists whereas the normal definition can succeed with non lists in ....

Lee Naish. Types and the intended meaning of logic programs. In Frank Pfenning, editor, Types in logic programming, pages 189--216. MIT Press, Cambridge, Massachusetts, 1992.

No context found.

Lee Naish. Types and the intended meaning of logic programs. In Frank Pfenning, editor, Types in logic programming, pages 189--216. MIT Press, Cambridge, Massachusetts, 1992.

No context found.

L. Naish, "Types and the Intended Meaning of Logic Programs," in [17], pp. 189--216.

No context found.

Lee Naish, Types and the intended meaning of logic programs, ed. Frank Pfenning, Types in logic programming, 189--216, (MIT Press, Cambridge, Massachusetts, 1992).

First 50 documents

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