How to replace failure by a list of successes a method for exception handling, backtracking, and pattern matching in lazy functional languages

  • Philip Wadler
Conference paper
Part of the Lecture Notes in Computer Science book series (LNCS, volume 201)

Abstract

Should special features for exception handling, backtracking, or pattern matching be included in a programming language? This paper presents a method whereby some programs that use these features can be re-written in a functional language with lazy evaluation, without the use of any special features. This method may be of use for practicing functional programmers; in addition, it provides further evidence of the power of lazy evaluation. The method itself is straightforward: each term that may raise an exception or backtrack is replaced by a term that returns a list of values. In the special case of pattern matching without backtracking, the method can be applied even if lazy evaluation is not present. The method should be suitable for applications such as theorem proving using tacticals, as in ML/LCF.

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

References

  1. [Aho and Ullman 77]
    Aho, A. V., and Ullman, J. D. Principles of Compiler Design. Addison-Wesley, 1977.Google Scholar
  2. [Black 82]
    Black, A. P. Exception handling: the case against. D. Phil. dissertation, Oxford University, 1982. Also available as University of Washington technical report TR 82-01-02, 1982.Google Scholar
  3. [Bobrow and Raphael 74]
    Bobrow, D. G., and Raphael, B. New programming languages for artificial intelligence research. Computing Surveys, 6(3): 155–174, September 1974.Google Scholar
  4. [Friedman and Wise 76]
    Friedman, D. P., and Wise, D. S. Cons should not evaluate its arguments. In Michaelson and Milner (editors), Automata, Languages, and Programming, 257–284, Edinburgh University Press, 1976.Google Scholar
  5. [Gordon et al 79]
    Gordon, M. J., Milner, R., and Wadsworth, C. P. Edinburgh LCF. Lecture Notes in Computer Science 78. Springer-Verlag, 1979.Google Scholar
  6. [Griswold 82]
    Griswold, R. E. The evaluation of expressions in Icon. ACM Transactions on Programming Languages and Systems, 4(4): 563–584, October 1982.Google Scholar
  7. [Griswold 84]
    Griswold, R. E. The evaluation of expressions in Icon. Symposium on Lisp and Functional Programming, ACM, Austin, TX, August 1984.Google Scholar
  8. [Henderson and Morris 76]
    Henderson, P., and Morris, J. H. A lazy evaluator. in 3'rd Symposium on Principals of Programming Languages, 95–103, ACM, Atlanta, GA, 1976.Google Scholar
  9. [Henderson 80]
    Henderson, P. Functional Programming: Application and Implementation. Prentice-Hall, 1980.Google Scholar
  10. [Kowalski 79]
    Kowalski, R. Algorithm = Logic + Control. Communications of the ACM, 22(7), July, 1979.Google Scholar
  11. [Morris et al 80]
    Morris, J. H., Schmidt, E., and Wadler, P. L. Experience with an applicative string processing language. 7'th Symposium on Principles of Programming Languages, ACM, Las Vegas, Nevada, 1980.Google Scholar
  12. [Paulson 83]
    Rewriting in Cambridge LCF. Science of Computer Programming, 3: 119–149, Sept., 1983.Google Scholar
  13. [Turner 81]
    Turner, D. A. Recursion equations as a programming language. In Darlington, et al (editors), Functional Programming and Its Applications, Cambridge University Press, 1981.Google Scholar
  14. [Wadler 85]
    Wadler, P. L. A splitting headache: Strict vs. lazy semantics for pattern matching in lazy functional languages. To appear.Google Scholar

Copyright information

© Springer-Verlag 1985

Authors and Affiliations

  • Philip Wadler
    • 1
  1. 1.Programming Research GroupOxford UniversityOxford

Personalised recommendations