Skip to main content Accessibility help

We use cookies to distinguish you from other users and to provide you with a better experience on our websites. Close this message to accept cookies or find out how to manage your cookie settings.

Close cookie message
×
  1. Home
  2. Browse subjects
  3. Computer Science
  4. Programming Languages and Applied Logic
  5. Content listing

Refine search

Refine search

Access:
Content type:
Publication date:
Apply   From and To filters
Subject: Show more
Journals Show more
Publishers: Show more
Societies Show more
Series: Show more
Collections: Show more

Actions for selected content:

Select all | Deselect all
  • View selected items
  • Export citations
  • Download PDF (zip)
  • Save to Kindle
  • Save to Dropbox
  • Save to Google Drive

Save Search

You can save your searches here and later view and run them again in "My saved searches".

Please provide a title, maximum of 40 characters.
Cancel
×

5644 results in Programming Languages and Applied Logic

Page 276 of 283

  • 9 - Abstract data types

  • R. G. Stone, D. J. Cooke
  • Book:
    Program Construction
    Published online:
    05 June 2012
    Print publication:
    05 February 1987, pp 227-261

  • Summary

    Most programming languages allow programmer defined data structures (e.g. array … of …) and when there is a rich choice available (array, record, set, pointer, etc.) there is no doubt that very neat, expressive data models can be built. However there is one major drawback. That is that the syntax used for accessing each type of structure is distinctive and fixed. This has two effects. Firstly, if for example, a list structure is altered from an array implementation to a record-with-pointer implementation then every reference to the list in the program must be changed. The distinctive array reference syntax (a[i]) has to be changed to record/pointer reference syntax (p↑. field). Secondly the program becomes more machine-oriented and less problem-oriented because of the intrusion of programming details.

    The way of avoiding the problems mentioned above is to think of a data structure not just as a storage area but as a collection of distinctive operations on certain data. This almost establishes the informal definition of an abstract data type (ADT)

    ADT = Data Structure + Distinctive Operations

    We have been using one abstract data type (the list) without naming it as such. Its distinctive operations are head and tail, ‘concatenate’ (∥) and ‘creation from elements’ (〈e1, e2, …, en〉). We have also introduced realisations or implementations of the abstract data type list in various languages – see Chapter 6. In fact in Section 6.3, Templates for FORTRAN, the implementation of LIST as a module shows the clear intention to treat the data space and the operations as an indivisible unit.

Page 276 of 283