{"title":"Efficient interpretation of Prolog programs","authors":"Jonas Barklund","doi":"10.1145/29650.29664","DOIUrl":"https://doi.org/10.1145/29650.29664","url":null,"abstract":"The paper focuses on three ideas for solving problems with writing interpreters for the logic programming language Prolog in Prolog and how to combine these ideas to an interpreter for Prolog which is both simple and efficient. The resulting interpreter system can be incorporated into a Prolog based on Warren's Abstract Machine and built mostly from existing parts of it. The interpreter has been implemented and is used in a Prolog system developed at Uppsala University.","PeriodicalId":414056,"journal":{"name":"SIGPLAN Conferences and Workshops","volume":"65 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1987-07-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121696053","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Constructive real interpretation of numerical programs","authors":"H. Boehm","doi":"10.1145/29650.29673","DOIUrl":"https://doi.org/10.1145/29650.29673","url":null,"abstract":"We explore the feasibility of providing exact real arithmetic for use in conventional numerical programs. We have built a prototype interpreter which replaces floating point operations with operations on constructive real numbers in the execution of conventional Fortran programs. Such a facility makes it unnecessary to concern oneself with issues of numerical stability in the solution of small problems. It also provides a useful tool for the development of larger numerical programs.We discuss the computability and algorithmic issues involved in the design of the interpreter, as well as some preliminary experiences and performance measurements.","PeriodicalId":414056,"journal":{"name":"SIGPLAN Conferences and Workshops","volume":"116 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1987-07-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"117199946","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"A recursive interpreter for the Icon programming language","authors":"Janalee O'Bagy, R. Griswold","doi":"10.1145/29650.29665","DOIUrl":"https://doi.org/10.1145/29650.29665","url":null,"abstract":"The implementation of the Icon programming language is more interesting and difficult than the implementation of many other programming languages because an expression in Icon can generate a sequence of results. The implementation therefore must support control backtracking in expression evaluation. There also are several novel control structures related to generators. Because expression evaluation is limited lexically, a full coroutine mechanism is not needed and expression evaluation can be handled in a stack-like fashion.The implementation of Icon consists of a virtual machine with a stack-based architecture and an interpreter that executes the virtual machine instructions. There have been several different interpreters for Icon's virtual machine. This paper describes a new approach in which the interpreter is called recursively whenever the context for expression evaluation changes. This recursive interpreter has the advantage of being conceptually clear and flexible without sacrificing efficiency.","PeriodicalId":414056,"journal":{"name":"SIGPLAN Conferences and Workshops","volume":"171 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1987-07-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123472727","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Parallelism, persistence and meta-cleanliness in the symmetric Lisp interpreter","authors":"D. Gelernter, S. Jagannathan, T. London","doi":"10.1145/29650.29679","DOIUrl":"https://doi.org/10.1145/29650.29679","url":null,"abstract":"Symmetric Lisp is a programming language designed around first-class environments, where an environment is a dictionary that associates names with definitions or values. In this paper we describe the logical structure of the Symmetric Lisp interpreter. In other interpreted languages, the interpreter is a virtual machine that evaluates user input on the basis of its own internal state. The Symmetric Lisp interpreter, on the other hand, is a simple finite-state machine with no internal state. Its role is to attach user input to whatever environment the user has specified; such environments are transparent objects created by, maintained by and fully accessible to the user. The interpreter's semantics are secondary to the semantics of environments in Symmetric Lisp: it is the environment-object to which an expression is attached, not the interpreter, that controls the evaluation of expressions.This arrangement has several consequences. Because environments in Symmetric Lisp are governed by a parallel evaluation rule, the Symmetric Lisp interpreter is a parallel interpreter. A Symmetric Lisp environment evaluates to another environment; a session with the interpreter therefore yields a well-defined environment object as its result. Users are free to write routines that manage these interpreter-created objects - routines that list the elements of a namespace, coalesce environments, maintain multiple name definitions and so on precisely because environment objects may be freely inspected and manipulated. Because a named environment may contain other named environments as elements, interpreter-created objects may be regarded as hierarchical file systems. Because of the parallel evaluation semantics of environments, the interpreter is well-suited as an interface to a concurrent, language-based computer system that uses Symmetric Lisp as its base language. We argue that - in short - a basic semantic simplification in Symmetric Lisp promises a correspondingly basic increase in power at the user-interpreter interface.","PeriodicalId":414056,"journal":{"name":"SIGPLAN Conferences and Workshops","volume":"21 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1987-07-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"131839144","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"The type inference and coercion facilities in the scratchpad II interpreter","authors":"R. Sutor, R. Jenks","doi":"10.1145/29650.29656","DOIUrl":"https://doi.org/10.1145/29650.29656","url":null,"abstract":"The Scratchpad II system is an abstract datatype programming language, a compiler for the language, a library of packages of polymorphic functions and parametrized abstract datatypes, and an interpreter that provides sophisticated type inference and coercion facilities. Although originally designed for the implementation of symbolic mathematical algorithms, Scratchpad II is a general purpose programming language. This paper discusses aspects of the implementation of the interpreter and how it attempts to provide a user friendly and relatively weakly typed front end for the strongly typed programming language.","PeriodicalId":414056,"journal":{"name":"SIGPLAN Conferences and Workshops","volume":"5 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1987-07-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123510945","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"A Fortran 77 interpreter for mutation analysis","authors":"A. Offutt, K. N. King","doi":"10.1145/29650.29669","DOIUrl":"https://doi.org/10.1145/29650.29669","url":null,"abstract":"Mutation analysis is a powerful technique for testing software systems. In the Mothra project, conducted at Georgia Tech's Software Engineering Research Center, mutation analysis is used as a basis for building an integrated software testing environment. Mutation analysis requires the execution of many slightly differing versions of the same program to evaluate the quality of the data used to test the program. In the current version of the Mothra system, a program to be tested is translated to intermediate code, where it and its mutated versions are executed by an interpreter.In this paper, we discuss some of the unique requirements of an interpreter used in a mutation-based testing environment. We then describe how these requirements affected the design and implementation of the Fortran 77 version of the Mothra interpreter. Other topics covered include the architecture of the interpreter and many of the design elements that it incorporates. We also describe the intermediate language used by Mothra and the features of the interpreter that are needed for software testing.","PeriodicalId":414056,"journal":{"name":"SIGPLAN Conferences and Workshops","volume":"217 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1987-07-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115222094","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Cint: a RISC interpreter for the C programming language","authors":"J. Davidson, J. Gresh","doi":"10.1145/29650.29670","DOIUrl":"https://doi.org/10.1145/29650.29670","url":null,"abstract":"Cint is an interpretation system for the C programming language. Like most interpretation systems, it provides \"load and go\" type execution as well as enhanced debugging and performance analysis tools. Cint consists of two phases--a translator and an interpreter. The translator compiles the source program into code for a virtual machine. The interpreter then loads and executes this code. While providing services similar to traditional interpreters, Cint differs from them in two important ways. First, the virtual machine languages used by many interpreters are quite large; machines with 100 to 200 operations are common. In contrast, Cint's virtual machine has only 63 operations. Second, to achieve acceptable execution speeds, interpreters are often implemented in the assembly language of the host machine. Cint, however, is written entirely in C and is therefore portable. In fact, it has been transported to four machines without modification. Despite the compact size of the virtual machine language and the high-level language implementation, Cint's execution speed is comparable to that of other interpreters. This paper describes the design of the virtual machine, the implementation of the interpreter, and the performance of the system.","PeriodicalId":414056,"journal":{"name":"SIGPLAN Conferences and Workshops","volume":"99 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1987-07-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116106683","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Selective interpretation as a technique for debugging computationally intensive programs","authors":"B. B. Chase, R. Hood","doi":"10.1145/29650.29662","DOIUrl":"https://doi.org/10.1145/29650.29662","url":null,"abstract":"As part of Rice University's project to build a programming environment for scientific software, we have built a facility for program execution that solves some of the problems inherent in debugging large, computationally intensive programs. By their very nature such programs do not lend themselves to full-scale interpretation. In moderation however, interpretation can be extremely useful during the debugging process. In addition to discussing the particular benefits that we expect from interpretation, this paper addresses how interpretive techniques can be effectively used in conjunction with the execution of compiled code. The same implementation technique that permits interpretation to be incorporated as part of execution will also permit the execution facility to be used for debugging parallel programs running on a remote machine.","PeriodicalId":414056,"journal":{"name":"SIGPLAN Conferences and Workshops","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1987-07-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125020226","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Integrating code generation and optimization","authors":"C. Fraser, A. L. Wendt","doi":"10.1145/12276.13335","DOIUrl":"https://doi.org/10.1145/12276.13335","url":null,"abstract":"This paper describes a compiler with a code generator and machine-directed peephole optimizer that are tightly integrated. Both functions are performed by a single rule-based rewriting system that matches and replaces patterns. This organization helps make the compiler simple, fast, and retargetable. It also corrects certain phase-ordering problems.","PeriodicalId":414056,"journal":{"name":"SIGPLAN Conferences and Workshops","volume":"106 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1986-07-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"127326947","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Implementing RUSSELL","authors":"Hans-Juergen Boehm, Alan J. Demers","doi":"10.1145/12276.13330","DOIUrl":"https://doi.org/10.1145/12276.13330","url":null,"abstract":"We have completed an implementation of the Russell programming language [Don 85]. This effort has been very helpful in the evaluation of the original language design. It has also served to pinpoint the difficulties in implementing languages with type systems as general as that of Russell.\u0000Russell treats both functions and types as data objects which can be freely manipulated by the program. Most operators present in conventional programming languages are viewed as function calls. In spite of this, our compiler produces surprisingly efficient machine code, even with minimal effort invested in the code generator.\u0000The generality of the language served to simplify some aspects of the compiler. We focus on the separate compilation mechanism.\u0000The most difficult implementation problem is that of inferring typing information omitted by the programmer. We argue that this is an essential part of type checking a language such as Russell. Our current solution is only partially satisfactory.","PeriodicalId":414056,"journal":{"name":"SIGPLAN Conferences and Workshops","volume":"17 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1986-07-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"134149244","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}