Programming with Abstract Data Types.¶
Liskov, B., & Zilles, S. (1974). Programming with Abstract Data Types. ACM SIGPLAN Notices, 9(4), 50-59.
Cited by¶
4 citations across 4 artifacts.
Each citation links to the sentence it supports in the citing article.
Primes¶
- Abstract Data Type
- The role-versus-occupant split appears in software (interface, protocol), in legal and political systems (the office versus the office-holder), in organisations (job description versus incumbent), in biology (functional role versus molecular implementation), in mechanism design (the mechanism versus its instantiating institution), and in standards (the specification versus the implementing product).
This sourceFoundational statement of the abstract data type: a component specified by the behaviour of its operations while the implementation is hidden and substitutable, illustrated with stack-like examples; states the conformance/abstraction-function idea that any implementation must honour the specified behaviour.
- The role-versus-occupant split appears in software (interface, protocol), in legal and political systems (the office versus the office-holder), in organisations (job description versus incumbent), in biology (functional role versus molecular implementation), in mechanism design (the mechanism versus its instantiating institution), and in standards (the specification versus the implementing product).
- Abstraction
- Or does it diverge at the cases I need?
This sourceFoundational paper on abstract data types: programs structured as ADTs let one reason about and verify each module against its abstract specification independent of implementation, enabling substitution behind a stable interface — supports the irreversibility/ADT item and the operational-fidelity diagnostic.
- Or does it diverge at the cases I need?
- Boundary
- Liskov's concept of data abstraction barriers
This sourcefoundational statement of abstract-data-type / data-abstraction barriers — a stable interface hides the implementation behind it, i.e., the boundary between internal state and external interface is a design choice. [RE-SOURCED: the prior citation 'Liskov, B. (1972). A Note on A-7. ACM SIGPLAN Notices 7(2), 12–26' does not exist — SIGPLAN Notices Vol. 7 (1972) contains no Liskov paper and no paper titled 'A Note on A-7'.]
- Liskov's concept of data abstraction barriers
- Interface
- An interface is not merely a boundary; it is a contract specifying what gets exposed, what remains hidden, what signals cross, and what guarantees hold on each side, as Liskov and Zilles (1974) formalized in their treatment of abstract data types.
This sourceFoundational paper on abstract data types: argues that programs structured as collections of ADTs allow programmers to reason about and verify each module against its specification independently, enabling independent testing and substitution behind a stable interface.
- An interface is not merely a boundary; it is a contract specifying what gets exposed, what remains hidden, what signals cross, and what guarantees hold on each side, as Liskov and Zilles (1974) formalized in their treatment of abstract data types.
Verification¶
This reference passed the adversarial substantiation pipeline: it was checked to exist and to support the claim it is attached to. See how references were verified.
Registry ID ref:c920905f61a1 · see in the full table