Skip to main content Accessibility help
×
Hostname: page-component-76fb5796d-r6qrq Total loading time: 0 Render date: 2024-04-26T21:09:23.801Z Has data issue: false hasContentIssue false

44 - Type Abstractions and Type Classes

from Part XVII - Modularity

Published online by Cambridge University Press:  05 March 2016

Robert Harper
Affiliation:
Carnegie Mellon University, Pennsylvania
Get access

Summary

An interface is a contract that specifies the rights of a client and the responsibilities of an implementor. Being a specification of behavior, an interface is a type. In principle, any type may serve as an interface, but in practice it is usual to structure code into modules consisting of separable and reusable components. An interface specifies the behavior of a module expected by a client and imposed on the implementor. It is the fulcrum balancing the tension between separation and integration. As a rule, a module ought to have a welldefined behavior that can be understood separately, but it is equally important that it be easy to combine modules to form an integrated whole.

A fundamental question is, what is the type of a module? That is, what form should an interface take? One long-standing idea is that an interface is a labeled tuple of functions and procedures with specified types. The types of the fields of the tuple are often called function headers, because they summarize the call and return types of each function. Using interfaces of this form is called procedural abstraction, because it limits the dependencies between modules to a specified set of procedures. We may think of the fields of the tuple as being the instruction set of a virtual machine. The client makes use of these instructions in its code, and the implementor agrees to provide their implementations.

The problem with procedural abstraction is that it does not provide as much insulation as one might like. For example, a module that implements a dictionary must expose in the types of its operations the exact representation of the tree as, say, a recursive type (or, in more rudimentary languages, a pointer to a structure that itself may contain such pointers). Yet the client ought not depend on this representation: the purpose of abstraction is to get rid of pointers. The solution, as discussed in Chapter 17, is to extend the abstract machine metaphor to allow the internal state of the machine to be hidden from the client. In the case of a dictionary, the representation of the dictionary as a binary search tree is hidden by existential quantification. This concept is called type abstraction, because the type of the underlying data (state of the abstract machine) is hidden.

Type
Chapter
Information
Publisher: Cambridge University Press
Print publication year: 2016

Access options

Get access to the full version of this content by using one of the access options below. (Log in options will check for institutional or personal access. Content may require purchase if you do not have access.)

Save book to Kindle

To save this book to your Kindle, first ensure coreplatform@cambridge.org is added to your Approved Personal Document E-mail List under your Personal Document Settings on the Manage Your Content and Devices page of your Amazon account. Then enter the ‘name’ part of your Kindle email address below. Find out more about saving to your Kindle.

Note you can select to save to either the @free.kindle.com or @kindle.com variations. ‘@free.kindle.com’ emails are free but can only be saved to your device when it is connected to wi-fi. ‘@kindle.com’ emails can be delivered even when you are not connected to wi-fi, but note that service fees apply.

Find out more about the Kindle Personal Document Service.

  • Type Abstractions and Type Classes
  • Robert Harper, Carnegie Mellon University, Pennsylvania
  • Book: Practical Foundations for Programming Languages
  • Online publication: 05 March 2016
  • Chapter DOI: https://doi.org/10.1017/CBO9781316576892.046
Available formats
×

Save book to Dropbox

To save content items to your account, please confirm that you agree to abide by our usage policies. If this is the first time you use this feature, you will be asked to authorise Cambridge Core to connect with your account. Find out more about saving content to Dropbox.

  • Type Abstractions and Type Classes
  • Robert Harper, Carnegie Mellon University, Pennsylvania
  • Book: Practical Foundations for Programming Languages
  • Online publication: 05 March 2016
  • Chapter DOI: https://doi.org/10.1017/CBO9781316576892.046
Available formats
×

Save book to Google Drive

To save content items to your account, please confirm that you agree to abide by our usage policies. If this is the first time you use this feature, you will be asked to authorise Cambridge Core to connect with your account. Find out more about saving content to Google Drive.

  • Type Abstractions and Type Classes
  • Robert Harper, Carnegie Mellon University, Pennsylvania
  • Book: Practical Foundations for Programming Languages
  • Online publication: 05 March 2016
  • Chapter DOI: https://doi.org/10.1017/CBO9781316576892.046
Available formats
×