scispace - formally typeset
Search or ask a question
Journal ArticleDOI

Protection in programming languages

01 Jan 1973-Communications of The ACM (ACM)-Vol. 16, Iss: 1, pp 15-21
TL;DR: Linguistic mechanisms which can be used to protect one subprogram from another's malfunctioning are described and an attempt is made to distinguish between access limitation and authentication.
Abstract: Linguistic mechanisms which can be used to protect one subprogram from another's malfunctioning are described. Function-producing functions and various type-tagging schemes are considered. An attempt is made to distinguish between access limitation and authentication.

Content maybe subject to copyright    Report

Citations
More filters
Journal ArticleDOI
01 Sep 1975
TL;DR: In this article, the authors explore the mechanics of protecting computer-stored information from unauthorized use or modification, focusing on those architectural structures-whether hardware or software-that are necessary to support information protection.
Abstract: This tutorial paper explores the mechanics of protecting computer-stored information from unauthorized use or modification. It concentrates on those architectural structures-whether hardware or software-that are necessary to support information protection. The paper develops in three main sections. Section I describes desired functions, design principles, and examples of elementary protection and authentication mechanisms. Any reader familiar with computers should find the first section to be reasonably accessible. Section II requires some familiarity with descriptor-based computer architecture. It examines in depth the principles of modern protection architectures and the relation between capability systems and access control list systems, and ends with a brief analysts of protected subsystems and protected objects. The reader who is dismayed by either the prerequisites or the level of detail in the second section may wish to skip to Section III, which reviews the state of the art and current research projects and provides suggestions for further reading.

2,063 citations

Book ChapterDOI
09 Apr 1974
TL;DR: It can be shown that B maps every type expression into a functor from C T into C, that w = w' implies w[w] = B[w'], and that B[WlI: 2](~) = B [Wl][ D I t I B[ w2](D) ]
Abstract: 7)(D) = B[w][71t]#D] and delta is a functor from Funct(C, C) into C. Even before defining the functors arrow and delta, it can be shown that B maps every type expression into a functor from C T into C, that w = w' implies B[w] = B[w'], and that B[WlI: 2](~) = B[Wl][ D I t I B[w2](D) ] B[WlI~2](7) = B[Wl][ ~ I t I B[w2](~) ]

936 citations

Proceedings ArticleDOI
TL;DR: An approach which allows the set of built-in abstractions to be augmented when the need for a new data abstraction is discovered and is an outgrowth of work on designing a language for structured programming.
Abstract: 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.

721 citations

Journal ArticleDOI
TL;DR: This paper provides an introduction to the abstraction mechanisms in CLU by means of programming examples, and it is shown how CLU programs may be written to use and implement abstractions.
Abstract: CLU is a new programming language designed to support the use of abstractions in program construction. Work in programming methodology has led to the realization that three kinds of abstractions—procedural, control, and especially data abstractions—are useful in the programming process. Of these, only the procedural abstraction is supported well by conventional languages, through the procedure or subroutine. CLU provides, in addition to procedures, novel linguistic mechanisms that support the use of data and control abstractions. This paper provides an introduction to the abstraction mechanisms in CLU. By means of programming examples, the utility of the three kinds of abstractions in program construction is illustrated, and it is shown how CLU programs may be written to use and implement abstractions. The CLU library, which permits incremental program development with complete type checking performed at compile time, is also discussed.

701 citations

01 Jan 1987
TL;DR: This paper investigates the usefulness of hierarchy in program development, and concludes that although data abstraction is the more important idea, hierarchy does extend its usefulness in some situations.
Abstract: Data abstraction is a valuable method for organizing programs to make them easier to modify and maintain. Inheritance allows one implementation of a data abstraction to be related to another hierarchically. This paper investigates the usefulness of hierarchy in program development, and concludes that although data abstraction is the more important idea, hierarchy does extend its usefulness in some situations.

346 citations


Cites background from "Protection in programming languages..."

  • ...(This view was first described by Morris [14].)...

    [...]

  • ...Morris, J. H. "Protection in Programming Languages"....

    [...]

  • ...(This view was first described by Morris [14]....

    [...]

References
More filters
Journal ArticleDOI
TL;DR: The semantics are defined for a number of meta-instructions which perform operations essential to the writing of programs in multiprogrammed computer systems.
Abstract: The semantics are defined for a number of meta-instructions which perform operations essential to the writing of programs in multiprogrammed computer systems. These meta-instructions relate to parallel processing, protecting of separate computations, program debugging, and the sharing among users of memory segments and other computing objects, the names of which are hierarchically structured. The language sophistication contemplated is midway between an assembly language and an advanced algebraic language.

720 citations

Journal ArticleDOI
P. J. Landin1
TL;DR: A family of unimplemented computing languages is described that is intended to span differences of application area by a unified framework that dictates the rules about the uses of user-coined names, and the conventions about characterizing functional relationships.
Abstract: A family of unimplemented computing languages is described that is intended to span differences of application area by a unified framework. This framework dictates the rules about the uses of user-coined names, and the conventions about characterizing functional relationships. Within this framework the design of a specific language splits into two independent parts. One is the choice of written appearances of programs (or more generally, their physical representation). The other is the choice of the abstract entities (such as numbers, character-strings, list of them, functional relations among them) that can be referred to in the language.The system is biased towards “expressions” rather than “statements.” It includes a nonprocedural (purely functional) subsystem that aims to expand the class of users' needs that can be met by a single print-instruction, without sacrificing the important properties that make conventional right-hand-side expressions easy to construct and understand.

637 citations

Book
01 Jan 1962
TL;DR: The LISP language is designed primarily for symbolic data processing used for symbolic calculations in differential and integral calculus, electrical circuit theory, mathematical logic, game playing, and other fields of artificial intelligence.
Abstract: The LISP language is designed primarily for symbolic data processing used for symbolic calculations in differential and integral calculus, electrical circuit theory, mathematical logic, game playing, and other fields of artificial intelligence.The manual describes LISP, a formal mathematical language. LISP differs from most programming languages in three important ways. The first way is in the nature of the data. In the LISP language, all data are in the form of symbolic expressions usually referred to as S-expressions, of indefinite length, and which have a branching tree-type of structure, so that significant subexpressions can be readily isolated. In the LISP system, the bulk of the available memory is used for storing S-expressions in the form of list structures. The second distinction is that the LISP language is the source language itself which specifies in what way the S-expressions are to be processed. Third, LISP can interpret and execute programs written in the form of S-expressions. Thus, like machine language, and unlike most other high level languages, it can be used to generate programs for further executions.

582 citations


"Protection in programming languages..." refers methods in this paper

  • ...The first language to allow procedures to be passed about was LISP, with its FUNARG lists [6]....

    [...]

Proceedings ArticleDOI
18 Nov 1969
TL;DR: This paper deals with one aspect of the subject, which might be called the meta-theory of protection systems: how can the information which specifies protection and authorizes access, itself be protected and manipulated.
Abstract: A very general problem which pervades the entire field of operating system design is the construction of protection mechanisms. These come in many different forms, ranging from hardware which prevents the execution of input/output instructions by user programs, to password schemes for identifying customers when they log onto a time-sharing system. This paper deals with one aspect of the subject, which might be called the meta-theory of protection systems: how can the information which specifies protection and authorizes access, itself be protected and manipulated. Thus, for example, a memory protection system decides whether a program P is allowed to store into location T. We are concerned with how P obtains this permission and how he passes it on to other programs.

205 citations


Additional excerpts

  • ...This mechanism is similar to the access key described in [4]; each Unseal~ plays the role of an access key....

    [...]

  • ...mos t no t ab ly , L a m p s o n [4], L a n d i n [5], R e y n o l d s [7],...

    [...]

Journal ArticleDOI
TL;DR: The functional approach to data structures and the use of references insure that any process which accepts some data structure will accept any logically equivalent structure, regardless of its internal representation.
Abstract: GEDANKEN is an experimental programming language with the following characteristics. (1) Any value which is permitted in some context of the language is permissible in any other meaningful context. In particular, functions and labels are permissible results of functions and values of variables. (2) Assignment and indirect addressing are formalized by introducing values, called references, which in turn possess other values. The assignment operation always affects the relation between some reference and its value. (3) All compound data structures are treated as functions. (4) Type declarations are not permitted. The functional approach to data structures and the use of references insure that any process which accepts some data structure will accept any logically equivalent structure, regardless of its internal representation. More generally, any data structure may be implicit; i.e. it may be specified by giving an arbitrary algorithm for computing or accessing its components. The existence of label variables permits the construction of co-routines, quasi-parallel processes, and other unorthodox control mechanisms. A variety of programming examples illustrates the generality of the language. Limitations and possible extensions are discussed briefly.

170 citations