Programming with Abstract Data Types.

Liskov, B., & Zilles, S. (1974). Programming with Abstract Data Types. ACM SIGPLAN Notices, 9(4), 50-59.

Type

Journal article

Intellectual base

Primary research

Year

1974

Volume

9

Issue

4

Pages

50-59

DOI

10.1145/942572.807045

DOI registrant

Association for Computing Machinery

Link

https://doi.org/10.1145/800233.807045

Cited from

computer_science, engineering_design, philosophy

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.

    Supported in partVerified against the work's full text

    Liskov and Zilles supply the software instance only: users see an abstract type's behaviour and never its implementation.

    “When a programmer makes use of an abstract data object, he is concerned only with the behavior which that ob- ject exhibits but not with any details of how that behavior is achieved by means of an implementation.”

    Read by an automated reader; not a human review. How support was checked

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

    Supported in partVerified against the work's full text

    In this paper clients of an abstract type cannot see or use hidden implementation detail; this is a design property of ADTs, not a general claim about abstraction.

    “In fact, he is unable to make use of implementation de- tails, leading to an improvement in program quality”

    Read by an automated reader; not a human review. How support was checked

• 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'.]

    SupportedVerified against the work's full text

    Liskov and Zilles present the abstract data type as exposing only an object's behaviour while hiding its representation and implementation from the user.

    “he need only be aware of the behavior of an abstract object, which is precisely the information he needs to write his program, and irrelevant details about how the object is represented in storage and how the operations are implemented, are hidden from him.”

    Read by an automated reader; not a human review. How support was checked

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

    Supported in partVerified against the work's full text

    Liskov and Zilles formalize the exposed-operations versus hidden-implementation split of abstract data types, but do not frame it as a contract with guarantees on each side.

    “irrelevant details about how the object is represented in storage and how the operations are implemented, are hidden from him.”

    Read by an automated reader; not a human review. How support was checked

Verification

Does it exist? Not checked yet. This work's DOI is recorded above but has not been resolved against an external catalogue, so nothing here confirms the work exists.

Does it back the claim? Read against the text for 4 of 4 citations: 1 supported, 3 supported in part. Each verdict is shown under its citation below, with what in the work backs the sentence.

Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.

See how references were verified.

Links previously used in the corpus

Before the registry existed this work was also linked 1 other way.

• https://doi.org/10.1145/942572.807045 ×1

Registry ID ref:c920905f61a1 · see in the full table