Gerald: An Exceptional Lazy Functional Programming Language

  • A. C. Reeves
  • D. A. Harrison
  • A. F. Sinclair
  • P. Williamson
Part of the Workshops in Computing book series (WORKSHOPS COMP.)


The availability of an exception handling mechanism can, with judicious use, greatly aid the clarity of code, allowing the programmer to separate the code to handle unusual situations from the code for the normal case. We describe an exception handling mechanism for a lazy functional language. The system proposed allows expressions which might raise an exception to be evaluated lazily, preserves referential transparency and has no dependence on reduction sequence. Exceptions are parameterised and are statically bound to recovery code. There are two strategies for recovery: resume which replaces the expression signaling an exception with the recovery code; and terminate which replaces the expression signaling the exception at the nearest firewall with the recovery code. Firewalls are used to bound terminate handlers, this allows the preservation of lazy evaluation where exceptions may be raised. A system of priorities is introduced on exceptions, which allow the programmer to indicate which exception is more serious, should a conflict occur. We discuss the approach proposed with reference to present systems.


Functional Programming Exception Handling System Exception Functional Programming Language Void Parameter 
These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.


Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.


  1. [1]
    Cristian F.; Robust data types,Acta Informatica 17, 1982, pp365–397.MathSciNetGoogle Scholar
  2. [2]
    Cristian F.; Dependable programs: Concepts and terminology, IBM Research laboratory San Jose, C.A., 1986 ( Technical Report).Google Scholar
  3. [3]
    Goodenough J.B.; Exception handling: Issues and a proposed notation,Comm ACM, Vol 18, No 12, 1975, pp513–519.CrossRefMathSciNetGoogle Scholar
  4. [4]
    Yemini S., Berry D.M.; A modular verifiable exception handling mechanism, ACM TOPLAS, Vol 7, No 2, 1985, pp 214–243.CrossRefGoogle Scholar
  5. [5]
    Yemini S., Berry D.M.; An axiomatic treatment of exception handling in an expression-oriented language, ACM TOPLAS, Vol 9, No 3, 1987, pp 390–407.CrossRefMATHGoogle Scholar
  6. [6]
    Bretz M., Ebert J.; An exception handling construct for functional languages,Proceedings ESOP88, 2nd European Symposium on Programming, Nancy, France, March 1988, LNCS 300, Springer-Verlag.Google Scholar
  7. [7]
    Landin P.J.; The next 700 programming languages,Comm ACM, Vol 6, No 3, 1966, pp157–166.CrossRefGoogle Scholar
  8. [8]
    Harper R., MacQueen D., Milner R.; Standard ML, LFCS-86–2. Laboratory for Foundations of Computer Science, University of Edinburgh, March 1986.Google Scholar
  9. [9]
    Hammond K.; Error Handling in the Parallel Implementation of a Lazy Functional Language, Internal Report SYS—C89–01, School of Information Systems, University of East Anglia, 1988.Google Scholar
  10. [10]
    Broy M.; Applicative Real-Time Programming,Proceedings IFIP 1983. North-Holland Information Processing 83.Google Scholar
  11. [11]
    Caspi P., Pilaud D., Halbwachs N., Plaice J.A.; LUSTRE: A Declarative Language for Programming Synchronous Systems, Conference Record of the 14th Annual ACM Symposium on Principles of Programming Languages, January 1987.Google Scholar
  12. [12]
    Harrison D.; RUTH: A Functional Language for Real-Time Programming,Proceedings Parallel Architectures and Languages Europe, Eindhoven, June 1987, LNCS 259, Springer-Verlag.Google Scholar
  13. [13]
    Harrison D.; Functional Real-Time Programming: The Language Ruth And Its Semantics, Ph.D. Thesis, University of Stirling, Stirling, Scotland, Submitted September 1988.Google Scholar
  14. [14]
    Karlsson K.; Nebula — A functional operating system, Laboratory for Programming Methodology, Department of Computer Science, Chalmers University, 1981.Google Scholar
  15. [15]
    Henderson P.; Purely functional operating systems, In Functional programming and its applications, Eds Darlington, Henderson and Turner, CUP, 1982.Google Scholar
  16. [16]
    Jones S.B.; A range of operating systems written in a purely functional style, Programming Research Group Technical Monograph PRG-42, Oxford University, September 1984.Google Scholar
  17. [17]
    Abramsky S.; Dynamically reconfigurable process networks: an applicative approach, Internal report, Computer Systems Laboratory, Queen Mary College, 1982.Google Scholar
  18. [18]
    Stoye W.; The implementation of functional languages using custom hardware, Ph.D. Thesis, Technical Report 81, University of Cambridge, December 1985.Google Scholar
  19. [19]
    Perry N.; Hope+C, A continuation extension for Hope+, IC FPR LANG 2.5.1 21, Department of Computing, Imperial College, November 1987.Google Scholar
  20. [20]
    Jones S.B., Sinclair A.F.; Functional programming and operating systems, The Computer Journal, Vol 32, No 2, 1989, pp 162–174.CrossRefGoogle Scholar
  21. [21]
    Turner D.A.; An introduction to Miranda, In The Implementation of Functional Programming Languages by S. L. Peyton Jones. Prentice Hall International Series in Computer Science. Ed C. A. R. Hoare. London 1987.Google Scholar
  22. [22]
    Johnsson T.; Compiling lazy functional languages, Ph.D. Thesis, Chalmers University of Technology, Goteborg, Sweden, 1987.Google Scholar

Copyright information

© British Computer Society 1990

Authors and Affiliations

  • A. C. Reeves
    • 1
  • D. A. Harrison
    • 1
  • A. F. Sinclair
    • 1
  • P. Williamson
    • 1
  1. 1.Department of Computing ScienceUniversity of StirlingStirlingUK

Personalised recommendations