scholarly journals Tree-Shaped Formats of Address Programming Language

2021 ◽  
Vol 4 ◽  
pp. 78-87
Author(s):  
Yury Yuschenko
Keyword(s):  
Programming Languages ◽  
Programming Language ◽  
Theoretical Research ◽  
Direct Access ◽  
Complex Data ◽  
Abstract Data Types ◽  
Data Types ◽  
Abstract Data ◽  
The One ◽  
High Level

In the Address Programming Language (1955), the concept of indirect addressing of higher ranks (Pointers) was introduced, which allows the arbitrary connection of the computer’s RAM cells. This connection is based on standard sequences of the cell addresses in RAM and addressing sequences, which is determined by the programmer with indirect addressing. Two types of sequences allow programmers to determine an arbitrary connection of RAM cells with the arbitrary content: data, addresses, subroutines, program labels, etc. Therefore, the formed connections of cells can relate to each other. The result of connecting cells with the arbitrary content and any structure is called tree-shaped formats. Tree-shaped formats allow programmers to combine data into complex data structures that are like abstract data types. For tree-shaped formats, the concept of “review scheme” is defined, which is like the concept of “bypassing” trees. Programmers can define multiple overview diagrams for the one tree-shaped format. Programmers can create tree-shaped formats over the connected cells to define the desired overview schemes for these connected cells. The work gives a modern interpretation of the concept of tree-shaped formats in Address Programming. Tree-shaped formats are based on “stroke-operation” (pointer dereference), which was hardware implemented in the command system of computer “Kyiv”. Group operations of modernization of computer “Kyiv” addresses accelerate the processing of tree-shaped formats and are designed as organized cycles, like those in high-level imperative programming languages. The commands of computer “Kyiv”, due to operations with indirect addressing, have more capabilities than the first high-level programming language – Plankalkül. Machine commands of the computer “Kyiv” allow direct access to the i-th element of the “list” by its serial number in the same way as such access is obtained to the i-th element of the array by its index. Given examples of singly linked lists show the features of tree-shaped formats and their differences from abstract data types. The article opens a new branch of theoretical research, the purpose of which is to analyze the expe- diency of partial inclusion of Address Programming in modern programming languages.

scholarly journals A Constructive Approach to Compiler Correctness

1980 ◽  
Vol 9 (118) ◽  
Author(s):  
Peter D. Mosses
Keyword(s):  
Programming Languages ◽  
Target Language ◽  
Constructive Approach ◽  
Abstract Data Types ◽  
Machine Code ◽  
Data Types ◽  
Denotational Semantic ◽  
Abstract Data ◽  
The One ◽  
Semantic Definition

<br /> It is suggested that denotational semantic definitions of programming languages should be based on a small number of abstract data types, each embodying a fundamental concept of computation. Once these fundamental abstract data types have been implemented in a particular target language (e.g. stack-machine code), it is a simple matter to construct a correct compiler for any source language from its denotational semantic definition. The approach is illustrated by constructing a compiler similar to the one which was proved correct by Thatcher, Wagner <em>Et</em> Wright ( 1979). Some familiarity with many-sorted algebras is presumed.

scholarly journals The ins and outs of Clean I/O

1995 ◽  
Vol 5 (1) ◽  
pp. 81-110 ◽  
Author(s):  
Peter Achten ◽  
Rinus Plasmeijer
Keyword(s):  
Programming Languages ◽  
Programming Language ◽  
Functional Programming ◽  
Data Types ◽  
Spreadsheet Program ◽  
Functional Programming Languages ◽  
Hard Time ◽  
Functional Programming Language ◽  
Algebraic Data Types ◽  
High Level

AbstractFunctional programming languages have banned assignment because of its undesirable properties. The reward of this rigorous decision is that functional programming languages are side-effect free. There is another side to the coin: because assignment plays a crucial role in Input/Output (I/O), functional languages have a hard time dealing with I/O. Functional programming languages have therefore often been stigmatised as inferior to imperative programming languages because they cannot deal with I/O very well. In this paper, we show that I/O can be incorporated in a functional programming language without loss of any of the generally accepted advantages of functional programming languages. This discussion is supported by an extensive account of the I/O system offered by the lazy, purely functional programming language Clean. Two aspects that are paramount in its I/O system make the approach novel with respect to other approaches. These aspects are the technique of explicit multiple environment passing, and the Event I/O framework to program Graphical User I/O in a highly structured and high-level way. Clean file I/O is as powerful and flexible as it is in common imperative languages (one can read, write, and seek directly in a file). Clean Event I/O provides programmers with a high-level framework to specify complex Graphical User I/O. It has been used to write applications such as a window-based text editor, an object based drawing program, a relational database, and a spreadsheet program. These graphical interactive programs are completely machine independent, but still obey the look-and-feel of the concrete window environment being used. The specifications are completely functional and make extensive use of uniqueness typing, higher-order functions, and algebraic data types. Efficient implementations are present on the Macintosh, Sun (X Windows under Open Look) and PC (OS/2).

scholarly journals A Semantic Algebra for Binding Constructs

1982 ◽  
Vol 10 (132) ◽  
Author(s):  
Peter D. Mosses
Keyword(s):  
Programming Languages ◽  
Denotational Semantics ◽  
Abstract Data Types ◽  
Data Types ◽  
Abstract Data ◽  
Algebraic Operators

This paper presents a semantic algebra, suitable for use in giving the denotational semantics of various forms of declarations and binding constructs in programming languages. The emphasis of the paper is on the development of semantic descriptions which are easy to understand at an intuitive level, being based on algebraic operators corresponding to fundamental concepts of programming languages. Some familiarity with denotational semantics and abstract data types is assumed.

The Formal Design Models of a Set of Abstract Data Types (ADTs)

2010 ◽  
Vol 2 (4) ◽  
pp. 72-100 ◽  
Author(s):  
Yingxu Wang ◽  
Xinming Tan ◽  
Cyprian F. Ngolah ◽  
Philip Sheu
Keyword(s):  
Real Time ◽  
Architectural Design ◽  
Cognitive Learning ◽  
Process Models ◽  
Complex Data ◽  
Abstract Data Types ◽  
Data Types ◽  
Real Time System ◽  
Dynamic Behaviors ◽  
Abstract Data

Type theories are fundamental for underpinning data object modeling and system architectural design in computing and software engineering. Abstract Data Types (ADTs) are a set of highly generic and rigorously modeled data structures in type theory. ADTs also play a key role in Object-Oriented (OO) technologies for software system design and implementation. This paper presents a formal modeling methodology for ADTs using the Real-Time Process Algebra (RTPA), which allows both architectural and behavioral models of ADTs and complex data objects. Formal architectures, static behaviors, and dynamic behaviors of a set of ADTs are comparatively studied. The architectural models of the ADTs are created using RTPA architectural modeling methodologies known as the Unified Data Models (UDMs). The static behaviors of the ADTs are specified and refined by a set of Unified Process Models (UPMs) of RTPA. The dynamic behaviors of the ADTs are modeled by process dispatching technologies of RTPA. This work has been applied in a number of real-time and non-real-time system designs such as a Real-Time Operating System (RTOS+), a Cognitive Learning Engine (CLE), and the automatic code generator based on RTPA.

Abstract data types in the Model programming language

1976 ◽  
Vol 11 (SI) ◽  
pp. 36-46 ◽  
Author(s):  
Robert T. Johnson ◽  
James B. Morris
Keyword(s):  
Programming Language ◽  
Abstract Data Types ◽  
Data Types ◽  
Abstract Data

An Interpretability Approach to the Theory of Abstract Data Types1

1983 ◽  
Vol 6 (3-4) ◽  
pp. 297-332
Author(s):  
Wiktor Dańko
Keyword(s):  
Programming Languages ◽  
Dynamic Logic ◽  
Abstract Data Types ◽  
Data Types ◽  
Abstract Data ◽  
Algorithmic Logic

In this paper, similarly to [1,4,17,20,21,29,30], abstract data types are understood as formalized many-sorted theories based on algorithmic languages (e.g. a language of algorithmic logic [2,16] or a language of dynamic logic [11,29]). Operations on data types, leading from (more) primitive types to compound types, are defined in terms of the interpretability theory (cf. Szczerba [25]). The approach proposed here to defining new types accords with the methods of introducing new classes of objects in programming languages like Simula 67, Pascal, Loglan, Ada.

scholarly journals Abstract Semantic Algebras!

1982 ◽  
Vol 11 (145) ◽  
Author(s):  
Peter D. Mosses
Keyword(s):  
Programming Languages ◽  
Programming Language ◽  
Conceptual Analysis ◽  
Formal Description ◽  
Data Types ◽  
New Approach ◽  
Initial Algebra ◽  
Language Semantics ◽  
Abstract Data ◽  
Initial Algebra Semantics

A new approach to the formal description of programming language semantics is described and illustrated. ''Abstract semantic algebras'' are just algebraically-specified abstract data types whose operations correspond to fundamental concepts of programming languages. The values of abstract semantic algebras are taken as meanings of programs in Denotational (or Initial Algebra) Semantics, instead of using Scott domains. This leads to semantic descriptions that clearly exhibit the underlying conceptual analysis, and which are rather easy to modify and extend. Some basic abstract semantic algebras corresponding to fundamental concepts of programming languages are given; they could be used in the description of many different programming languages.

Pattern matching with abstract data types

1993 ◽  
Vol 3 (2) ◽  
pp. 171-190 ◽  
Author(s):  
F. Warren Burton ◽  
Robert D Cameron
Keyword(s):  
Programming Languages ◽  
Pattern Matching ◽  
Functional Programming ◽  
Abstract Data Types ◽  
Data Types ◽  
Functional Programming Languages ◽  
Equational Reasoning ◽  
Abstract Data ◽  
Algebraic Data Types ◽  
Lazy Functional Programming

AbstractPattern matching in modern functional programming languages is tied to the representation of data. Unfortunately, this is incompatible with the philosophy of abstract data types.Two proposals have been made to generalize pattern matching to a broader class of types. The laws mechanism of Miranda allows pattern matching with non-free algebraic data types. More recently, Wadler proposed the concept of views as a more general solution, making it possible to define arbitrary mappings between a physical implementation and a view supporting pattern matching. Originally, it was intended to include views in the new standard lazy functional programming language Haskell.Laws and views each offer important advantages, particularly with respect to data abstraction. However, if not used with great care, they also introduce serious problems in equational reasoning. As a result, laws have been removed from Miranda and views were not included in the final version of Haskell.We propose a third approach which unifies the laws and views mechanisms while avoiding their problems. Philosophically, we view pattern matching as a bundling of case recognition and component selection functions instead of a method for inverting data construction. This can be achieved by removing the implied equivalence between data constructors and pattern constructors. In practice, we allow automatic mapping into a view but not out of the view. We show that equational reasoning can still be used with the resulting system. In fact, equational reasoning is easier, since there are fewer hidden traps.

Sign in / Sign up

Export Citation Format

Share Document