ArticlePDF Available

Report on the programming language EUCLID

DOI:10.1145/954666.971189
Authors:
Butler Lampson at Microsoft
Butler Lampson
J. J. Horning
J. J. Horning
J. J. Horning
  • This person is not on ResearchGate, or hasn't claimed this research yet.
R. L. London
R. L. London
R. L. London
  • This person is not on ResearchGate, or hasn't claimed this research yet.
J. G. Mitchell
J. G. Mitchell
J. G. Mitchell
  • This person is not on ResearchGate, or hasn't claimed this research yet.
Show all 5 authorsHide
Download full-text PDFDownload full-text PDF
Read full-text
Download citation

Abstract

The programming language Euclid has been designed to facilitate the construction of verifiable system programs. By a verifiable program we mean one written in such a way that existing formal techniques for proving certain properties of programs can be readily applied; the proofs might be either manual or automatic, and we believe that similar considerations apply in both cases. By system we mean that the programs of interest are part of the basic software of the machine on which they run; such a program might be an operating system kernel, the core of a data base management system, or a compiler. An important consequence of this goal is that Euclid is not intended to be a general-purpose programming language. Furthermore, its design does not specifically address the problems of constructing very large programs; we believe most of the programs written in Euclid will be modest in size. While there is some experience suggesting that verifiability supports other desired goals, we assume the user is willing, if necessary, to obtain verifiability by giving up some run-time efficiency, and by tolerating some inconvenience in the writing of his programs.
0c960521525241487e0000
00.pdf
Content uploaded by Butler Lampson
Author content
All content in this area was uploaded by Butler Lampson
Content may be subject to copyright.
17-EuclidRepo
rt.pdf
Content uploaded by Butler Lampson
Author content
All content in this area was uploaded by Butler Lampson
Content may be subject to copyright.
A preview of the PDF is not available
... For several years, it was used for systems programming and secure software system research at I. P. Sharp Associates, MITRE Corporation, SRI International, and numerous other international institutes. [174] ...
All Programming Languages, with Support of mayar
Book
Full-text available
  • Mar 2023
Abbreviation For All Programming Languages In One Book. The Goal of This Book Is To Contains All Names of Programming Languages In One Area, Whether These Languages are Ancient or Modern, and in English Alphabetical Order. Explanation of nearly 700 programming languages. How to write "Hello World "in several programming languages.
View
... This closed scope rule attempts to get around the problem of students always trying to pass data using global variables. It is similar to the scope rules of Alphard (Shaw 1981) or Euclid (Lampson, Horning et al. 1977). ...
G2 -A Design Language To Help Novice C Programmers
Conference Paper
Full-text available
  • Sep 1994
The aim of most introductory programming courses is not to teach the syntax of a programming language but to teach the principle of program design using the chosen language as.a vehicle for student expression. Teaching C as a first language is perceived to be a hard task because of the difficult syntax and unhelpful compilers. It was felt that students would have difficulty with the syntax and never be able to look beyond the syntax to consider the underlying principles of programming. The authors' solution to combat this problem was to develop a design language, G2. A design language is a language in which a program design can be expressed easily rather than a language such as Pascal or C where details of implementation dominate the program design. The problem with design languages and pseudo codes is that the student cannot see the results of the design unless it is translated into program code. If the student does the translation themselves then they become confused between the two languages and are hindered by the syntax of each. The G2 language is designed to be translated into C automatically. Thus the students only have to learn one language at the start of their studies. Built into the language are a number of features that promote good programming discipline but are not enforced by many programming languages. There is facility to separate abstract data types from the top down development of the code. The use of global variables is not allowed although types and constants are allowed to be global. The G2 code is designed to be read by people and the design is presented in a natural top down manner. This is in contrast to PASCAL where reading the code top down does not give the reader much insight into the program structure. The educational development is in three stages. Initially Students learn the G2 language and use the translator to produce programs for them. The C code matching the design is compiled and run. Once the students gain some familiarity with the language they are introduced to C. This is done using comparisons of the G2 design and the resulting code. Finally as there is no market for G2 programmers, the students have to learn to program in C. Hence in the final stage of the course the automatic translator is unavailable and the students are expected to design the program on paper and translate this into C themselves. The translation rules used by the G2 translator are used by the students to do this task. An informal evaluation of the results of the G2 experience is presented.
View
... Although Back doesn't indicate how this construct would be used, one would presumably require that T 0 be a refinement of T, and allow further refinement of S and T 0 , but not of T. A similar approach is being taken in the PRT refinement tool being developed at the University of Queensland [27]. This approach is closer to the way procedures are handled in Hoare logic [15], and has been incorporated in programming languages such as Alphard [31] and Euclid [17]. From a refinement point of view, it can be seen as recording information about the development of a program as part of the program text; this information is irrelevant to the final program and would be ignored by a compiler. ...
View
View
VALIDITY CONTRACTS FOR SAFE SOFTWARE TRANSACTIONS
Thesis
Full-text available
  • Jun 2009
Software Transactional Memory is a promising approach to concurrent programming, freeing programmers from error-prone concurrency control decisions. But few such systems address consistencies of transactional objects. In this thesis, I propose a contract-based transactional programming model toward more secure transactional softwares. In this model, I propose a validity contract specifying both requirements and effects for transactions. Validity contracts bring numerous benefits for reasoning about and verifying transactional programs, for detecting and resolving transactional conflicts, for automating object revalidation and for easing debugging of transactions programs. I introduce an ownership-based framework, namely AVID, derived from the general model, by using object ownership as a mechanism for specifying and reasoning validity contracts. I have implemented formal type system and a prototype checker to support static checking, and also have built an AVID transactional library framework. Experimental results on a multi-core system show that contracts add little overheads to the original STM. I find that contract-aware contention management yield significant speedups in some cases. This opens future compiler-directed optimization for tunning contract-based transactional programs.
View
Rationale for Comments: The Effect on Programming Languages and Implementation
Chapter
  • Jan 1985
Comments in programming languages have traditionally been used to add extra descriptive information to program source code in an informal manner; programmers have been encouraged to use commenting only as a means of creating readable code and specific code documentation. However, research currently being carried out indicates a dramatic change in the importance of comments within programs. This paper describes the changing role of comments, giving examples of new uses of program comments in the area of formal system specification and verification. The relative unimportance which language designers and implementors have associated with a comment facility is highlighted; the need for different types of comments and their syntactical representation is outlined. An increasing awareness of the power of software tools has lead to integrated programming environments which support the manipulation of source code and possibly its intermediate forms. This approach provides a base for tools to act upon comments in a functional way. Proposals are made which are intended to promote discussion on language design, implementation, and internal representation.
View
Name analysis for modern languages: A general solution
Article
  • Mar 2017
Classical strategies for matching identifier uses with declarations cannot handle the complexities of modern languages: arbitrarily qualified superclass names, cyclic dependence among lookup operations, and contextual access constraints. We have developed a language-independent algorithm and supporting data structure that overcome these problems. A well-defined interface allows introduction of arbitrary code to enforce language-specific constraints within the basic lookup operations. This paper explains the limitations of the classical strategies, presents the concepts on which our approach is based, and showcases an implementation based on attribute grammars. We explore the major issues through a series of examples and show how one can deal with those issues in a general framework. Many of the issues are specific to a particular language, and in those cases, we explain the solutions that our general interface supports. Although attribute grammars simplify the task of incorporating the model into a compiler, the model itself is completely independent of attribute grammars. We validated our model by using an implementation to process programs in several representative languages. In particular, we mechanically compared the results produced by that implementation with those produced by the Java SE 8 compiler on complete Java programs that are in general use. Performance data obtained during this processing show that our implementation is efficient. Copyright
View
Bibliography
Chapter
  • Jan 1983
This section contains 870 papers with useful bibliographic informations. Each item consists of four parts: name(s) of author(s) and year of issue title kind(s) of publication (separated by a plus-sign ‘+’) (optional:) references to citations in Zentralblatt fur Mathematik, Section 68B, (ZfM), Mathematical Reviews, Section 68B, (MR), Current Mathematical Publications, Section 68B, (CMP), Computer Abstracts, Sections Computer Theory and Programming, (CA)
View
Revealing Purity and Side Effects on Functions for Reusing Java Libraries
Conference Paper
  • Jan 2015
Reuse of software components requires the comprehension of the behavior and possible side effects among APIs of program components. Meanwhile, identifying problematic usage of these components is difficult with conventional static analysis. Purity and side effects are important properties of methods that often are neglected by the documentations of the object oriented languages such as Java. In this paper, we studied these properties by using a static analysis technique to automatically infer the state dependencies for the return value and side effects of methods. As a result, the effect information reveals purity of methods as well as well-defined state interactions between objects. We have implemented the analyzer targeting Java bytecode and tested it on some open source Java software libraries with different scale and characteristic. From our experimental results, we found that 24–44% of the methods in the evaluated open source Java libraries are pure, which indicates that a large percentage of the methods are suitable for high level refactoring. Our study can help programmers to understand and reuse these libraries.
View
A computer system supporting data abstraction
Article
  • Apr 1981
A computer system designed to support operating system facilities is formally specified. With the proposed technology, an operating system in the conventional sense of the word becomes superfluous. Instead, the facilities supported by e.g. a general-purpose operating system may be implemented as applications of the proposed computer system. This is made possible by the ability of the proposed system to support data abstraction rather than procedural abstraction as supported by conventional systems. The design is revolutionary in the integration of "processing" and "filing", as supported by the conventional systems "process" and "file" concepts. This is achieved by supporting a single system object, the "domain", which is an extension of the domain concept known in a number of systems. The capability concept will enable domains to reference each other in a network-like structure.A rationale for the use of data abstraction in operating systems can be found in [Madsen 79b].
View
Notes on the Design of Euclid
Article
Full-text available
Euclid is a language for writing system programs that are to be verified. We believe that verification and reliability are closely related, because if it is hard to reason about programs using a language feature, it will be difficult to write programs that use it properly. This paper discusses a number of issues in the design of Euclid, including such topics as the scope of names, aliasing, modules, type-checking, and the confinement of machine dependencies; it gives some of the reasons for our expectation that programming in Euclid will be more reliable (and will produce more reliable programs) than programming in Pascal, on which Euclid is based.
View
Programming with abstract data types
Article
  • Apr 1974
The motivation behind the work in very-high-level languages is to ease the programming task by providing the programmer with a language containing primitives or abstractions suitable to his problem area. The programmer is then able to spend his effort in the right place; he concentrates on solving his problem, and the resulting program will be more reliable as a result. Clearly, this is a worthwhile goal. Unfortunately, it is very difficult for a designer to select in advance all the abstractions which the users of his language might need. If a language is to be used at all, it is likely to be used to solve problems which its designer did not envision, and for which the abstractions embedded in the language are not sufficient. This paper presents an approach which allows the set of built-in abstractions to be augmented when the need for a new data abstraction is discovered. This approach to the handling of abstraction is an outgrowth of work on designing a language for structured programming. Relevant aspects of this language are described, and examples of the use and definitions of abstractions are given.
View
On the problem of uniform references to data structures
Article
The cost of a change to a large software system is often primarily a function of the size of the system rather than the complexity of the change. One reason for this is that programs which access some given data structure must operate on it using notations which are determined by its exact representation. Thus, changing how it is implemented may necessitate changes to the programs which access it. This paper develops a programming language notation and semantic interpretations which allow a program to operate on a data object in a manner which is dependent only on its logical or abstract properties and independent of its underlying concrete representation.
View
The programming language PASCAL
Article
In Part 1, the structure of a PASCAL program as a collection of declarations and statements was laid out. This part begins with a description of PASCAL's unique facilities for defining data types to suit a particular problem. Statements, the sequences of reserved words, identifiers and symbols that specify the actions in a PASCAL program, are then described.
View
Reflections on a language designed to write an operating system
Article
Project SUE is writing an extensible time-sharing operating system for the IBM System/360 using a high-level System Language designed especially for the purpose. This paper expresses opinions on the crucial issues in the design of such a language, based on the Project SUE experience.
View
View
View
LR Parsing
Article
An abstract is not available.
View
Gypsy: A language for specification and implementation of verifiable programs
Article
An introduction to the Gypsy programming and specification language is given. Gypsy is a high-level programming language with facilities for general programming and also for systems programming that is oriented toward communications processing. This includes facilities for concurrent processes and process synchronization. Gypsy also contains facilities for detecting and processing errors that are due to the actual running of the program in an imperfect environment. The specification facilities give a precise way of expressing the desired properties of the Gypsy programs. All of the features of Gypsy are fully verifiable, either by formal proof or by validation at run time. An overview of the language design and a detailed example program are given.
View
MODULA: a language for modular multiprogramming
Article
This paper defines a language called Modula, which is intended primarily for programming dedicated computer systems, including process control systems on smaller machines. The language is largely based on Pascal, but in addition to conventional block structure it introduces a so-called module structure. A module is a set of procedures, data types and variables, where the programmer has precise control over the names that are imported from and exported to the environment. Modula includes general multiprocessing facilities, namely processes, interface modules and signals. It also allows the specification of facilities that represent a computer's specific peripheral devices. Those given in this paper pertain to the PDP-11.
View