Abstract data types in Euclid

Authors:
Ernest Chang;Neil E. Kaden;W. David Elliott
Affiliations:
University of Toronto, Toronto, Ontario, Canada;University of Toronto, Toronto, Ontario, Canada;University of Toronto, Toronto, Ontario, Canada
Venue:
ACM SIGPLAN Notices
Year:
1978

Citing 9
Cited 2

Early experience with Mesa

Communications of the ACM
Abstraction mechanisms in CLU

Communications of the ACM
The treatment of data types in EL1

Communications of the ACM
Some desirable properties of data abstraction facilities

Proceedings of the 1976 conference on Data : Abstraction, definition and structure
A next step in data structuring for programming languages

Proceedings of the 1976 conference on Data : Abstraction, definition and structure
Gypsy: A language for specification and implementation of verifiable programs

Proceedings of an ACM conference on Language design for reliable software
Global variable considered harmful

ACM SIGPLAN Notices
Report on the programming language Euclid

ACM SIGPLAN Notices
SIMULA 67 common base language, (Norwegian Computing Center. Publication)

SIMULA 67 common base language, (Norwegian Computing Center. Publication)

Modular Verification of Data Abstractions with Shared Realizations

IEEE Transactions on Software Engineering
Capsules: A data abstraction facility for Pascal

ACM '81 Proceedings of the ACM '81 conference

Quantified Score

Hi-index	0.00

Visualization

Abstract

The programming language Euclid provides features that support abstract data types, but does not strictly speaking provide a true data abstraction mechanism. This paper assesses the data abstraction facilities that Euclid does provide, examines the two ways of instantiating Euclid modules, and discusses other features of modules that the designers of Euclid chose not to include. In particular, the paper addresses the issues of (1) enforceable separation between abstract definition and representation, (2) specifying the relationship between abstract definition and representation, (3) type parameters in modules, (4) operator extensions, and (5) scope restrictions on identifiers.