Hostname: page-component-848d4c4894-8kt4b Total loading time: 0 Render date: 2024-07-03T08:42:51.562Z Has data issue: false hasContentIssue false

Pattern matching with abstract data types1

Published online by Cambridge University Press:  07 November 2008

F. Warren Burton
Affiliation:
School of Computing Science, Simon Fraser University, Burnaby, British Columbia, CanadaV5A 1S6 (e-mail: burton@cs.sfu.ca)
Robert D Cameron
Affiliation:
School of Computing Science, Simon Fraser University, Burnaby, British Columbia, CanadaV5A 1S6 (e-mail: burton@cs.sfu.ca)
Rights & Permissions [Opens in a new window]

Abstract

Core share and HTML view are not available for this content. However, as you have access to this content, a full PDF is available via the ‘Save PDF’ action button.

Pattern matching in modern functional programming languages is tied to the representation of data. Unfortunately, this is incompatible with the philosophy of abstract data types.

Two proposals have been made to generalize pattern matching to a broader class of types. The laws mechanism of Miranda allows pattern matching with non-free algebraic data types. More recently, Wadler proposed the concept of views as a more general solution, making it possible to define arbitrary mappings between a physical implementation and a view supporting pattern matching. Originally, it was intended to include views in the new standard lazy functional programming language Haskell.

Laws and views each offer important advantages, particularly with respect to data abstraction. However, if not used with great care, they also introduce serious problems in equational reasoning. As a result, laws have been removed from Miranda and views were not included in the final version of Haskell.

We propose a third approach which unifies the laws and views mechanisms while avoiding their problems. Philosophically, we view pattern matching as a bundling of case recognition and component selection functions instead of a method for inverting data construction. This can be achieved by removing the implied equivalence between data constructors and pattern constructors. In practice, we allow automatic mapping into a view but not out of the view. We show that equational reasoning can still be used with the resulting system. In fact, equational reasoning is easier, since there are fewer hidden traps.

Type
Articles
Copyright
Copyright © Cambridge University Press 1993

References

Bird, R. and Wadler, P. 1988. Introduction to Functional Programming. Prentice Hall.Google Scholar
Hudak, P., Wadler, P., Arvind, , Boutel, B., Fairburn, J., Fasel, J., Hammond, K., Hughes, J., Johnsson, T., Kieburtz, D., Nikhil, R., Peyton Jones, S., Reeve, M., Wise, D. and Young, J. 1990. Report on the programming language Haskell: A non-strict purely functional language (Version 1.0). Technical Report YALEU/DCS/RR777, Yale University, Department of Computer Science.Google Scholar
Hudak, P., Peyton Jones, S. and Wadler, P., editors. 1988. Report on the Functional Programming Language Haskell: SIGPLAN Notices, 27 (5), 05 1992.Google Scholar
Thompson, S. 1986. Laws in Miranda. Proc. ACM Conference on LISP and Functional Programming, 112.Google Scholar
Thompson, S. 1990. Lawful functions and program verification in Miranda. Science of Computer Programming, 13 (2-3): 181218, 05.CrossRefGoogle Scholar
Turner, D. A. 1985. Miranda: A non-strict functional language with polymorphic types. In Jean-Pierre, Jouannaud, editor, Functional Programming Languages and Computer Architecture, Volume 201 of Lecture Notes in Computer Science, Springer-Verlag, 116.Google Scholar
Wadler, P. 1987. Views: A way for pattern matching to cohabit with data abstraction. Principles of Programming Languages 14, 307313.Google Scholar
Submit a response

Discussions

No Discussions have been published for this article.