scholarly journals FAD, a functional programming language that supports abstract data types

1980 ◽  
Author(s):  
Johannes J. Martin
Keyword(s):  
Programming Language ◽  
Functional Programming ◽  
Abstract Data Types ◽  
Data Types ◽  
Functional Programming Language ◽  
Abstract Data

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.

Encapsulating non-determinacy in an abstract data type with determinate semantics

1991 ◽  
Vol 1 (1) ◽  
pp. 3-20 ◽  
Author(s):  
F. Warren Burton
Keyword(s):  
Parallel Algorithms ◽  
Programming Language ◽  
Functional Programming ◽  
Data Type ◽  
Parallel Program ◽  
Abstract Data Type ◽  
Functional Programming Language ◽  
Abstract Data

AbstractA parallel program may be indeterminate so that it can adapt its behavior to the number of processors available.Indeterminate programs are hard to write, understand, modify or verify. They are impossible to debug, since they may not behave the same from one run to the next.We propose a new construct, a polymorphic abstract data type called an improving value, with operations that have indeterminate behavior but simple determinate semantics. These operations allow the type of indeterminate behavior required by many parallel algorithms.We define improving values in the context of a functional programming language, but the technique can be used in procedural programs as well.

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

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

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.

scholarly journals Functional programs as executable specifications

1984 ◽  
Vol 312 (1522) ◽  
pp. 363-388 ◽  
Keyword(s):  
Programming Language ◽  
Functional Programming ◽  
Function Spaces ◽  
Higher Order ◽  
Functional Languages ◽  
Specification Languages ◽  
Data Types ◽  
Executable Specifications ◽  
Functional Programming Language ◽  
Practical Necessity

To write specifications we need to be able to define the data domains in which we are interested, such as numbers, lists, trees and graphs. We also need to be able to define functions over these domains. It is desirable that the notation should be higher order, so that function spaces can themselves be treated as data domains. Finally, given the potential for confusion in specifications involving a large number of data types, it is a practical necessity that there should be a simple syntactic discipline that ensures that only well typed applications of functions can occur. A functional programming language with these properties is presented and its use as a specification tool is demonstrated on a series of examples. Although such a notation lacks the power of some imaginable specification languages (for example, in not allowing existential quantifiers), it has the advantage that specifications written in it are always executable. The strengths and weaknesses of this approach are discussed, and also the prospects for the use of purely functional languages in production programming.

Abstract data types in the Model programming language

1976 ◽  
Vol 8 (2) ◽  
pp. 36-46
Author(s):  
Robert T. Johnson ◽  
James B. Morris
Keyword(s):  
Programming Language ◽  
Abstract Data Types ◽  
Data Types ◽  
Abstract Data
Sign in / Sign up

Export Citation Format

Share Document