Proof Tool Support for Explicit Strictness

  • Marko van Eekelen
  • Maarten de Mol
Part of the Lecture Notes in Computer Science book series (LNCS, volume 4015)


In programs written in lazy functional languages such as for example Clean and Haskell, the programmer can choose freely whether particular subexpressions will be evaluated lazily (the default) or strictly (must be specified explicitly). It is widely known that this choice affects resource consumption, termination and semantics in several ways. However, functional programmers tend to be less aware of the consequences for logical program properties and formal reasoning.

This paper aims to give a better understanding of the concept of explicit strictness and its impact on properties and reasoning. It will be shown that explicit strictness may make reasoning more cumbersome, due to the introduction of additional definedness conditions.

Fortunately, these definedness conditions can be handled quite effectively by proof assistants. This paper describes the specific support that is offered by Sparkle for expressing and proving definedness conditions. This support makes reasoning with explicit strictness almost appear like reasoning without explicit strictness. To our knowledge, Sparkle is currently the only proof assistant with such strictness specific support.


Operational Semantic Logical Property Proof Assistant Functional Language Proof Rule 
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.
    Abel, A., Benke, M., Bove, A., Hughes, J., Norell, U.: Verifying Haskell programs using constructive type theory. In: Leijen, D. (ed.) Proceedings of the ACM SIGPLAN 2005 Haskell Workshop, Tallinn, Estonia, pp. 62–74. ACM Press, New York (2005)CrossRefGoogle Scholar
  2. 2.
    Baker-Finch, C., King, D., Trinder, P.: An operational semantics for parallel lazy evaluation. In: ACM-SIGPLAN International Conference on Functional Programming (ICFP 2000), Montreal, Canada, pp. 162–173 (2000)Google Scholar
  3. 3.
    Barendregt, H.P., van Eekelen, M.C.J.D., Glauert, J.R.W., Kennaway, R., Plasmeijer, M.J., Sleep, M.R.: Term graph rewriting. In: de Bakker, J.W., Nijman, A.J., Treleaven, P.C. (eds.) PARLE 1987. LNCS, vol. 259, pp. 141–158. Springer, Heidelberg (1987)Google Scholar
  4. 4.
    Burn, G.L.: Evaluation transformers – a model for the parallel evolution of functional languages. In: Kahn, G. (ed.) FPCA 1987. LNCS, vol. 274, pp. 446–470. Springer, Heidelberg (1987)Google Scholar
  5. 5.
    Danielsson, N.A., Jansson, P.: Chasing bottoms: A case study in program verification in the presence of partial and infinite values. In: Kozen, D. (ed.) MPC 2004. LNCS, vol. 3125, pp. 85–109. Springer, Heidelberg (2004)CrossRefGoogle Scholar
  6. 6.
    de Mol, M., van Eekelen, M., Plasmeijer, R.: Theorem proving for functional programmers. In: Arts, T., Mohnen, M. (eds.) IFL 2002. LNCS, vol. 2312, pp. 55–72. Springer, Heidelberg (2002)CrossRefGoogle Scholar
  7. 7.
    Dowse, M., Butterfield, A., van Eekelen, M.: A language for reasoning about concurrent functional i/o. In: Arts, T., Mohnen, M. (eds.) Selected Papers from the 16th International Workshop on Implementation and Application of Functional Languages, IFL 2004, Lübeck, Germany, LNCS, vol. 3074, pp. 177–195. Springer, Heidelberg (2004)Google Scholar
  8. 8.
    Gustavsson, J., Sands, D.: Possibilities and limitations of call-by-need space improvement. In: Proceedings of the sixth ACM SIGPLAN International Conference on Functional Programming, pp. 265–276. ACM Press, New York (2001)CrossRefGoogle Scholar
  9. 9.
    Johann, P., Voigtländer, J.: Free theorems in the presence of seq. In: Proceedings of the 31st ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, Venice, Italy, pp. 99–110 (2004)Google Scholar
  10. 10.
    van Kesteren, R., van Eekelen, M., de Mol, M.: Proof Support for General Type Classes. In: Intellect 2004 (to appear, 2004)Google Scholar
  11. 11.
    Koopman, P., Alimarine, A., Tretmans, J., Plasmeijer, R.: Gast: Generic automated software testing. In: Peña, R., Arts, T. (eds.) IFL 2002. LNCS, vol. 2670, pp. 84–100. Springer, Heidelberg (2003)CrossRefGoogle Scholar
  12. 12.
    Launchbury, J.: A natural semantics for lazy evaluation. In: Proceedings of the 20th Annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, Charleston, South Carolina, pp. 144–154 (1993)Google Scholar
  13. 13.
    Pitts, A.M.: Existential types: Logical relations and operational equivalence. In: Larsen, K.G., Skyum, S., Winskel, G. (eds.) ICALP 1998. LNCS, vol. 1443, pp. 309–326. Springer, Heidelberg (1998)CrossRefGoogle Scholar
  14. 14.
    Plasmeijer, R., van Eekelen, M.: Functional Programming and Parallel Graph Rewriting (1993), ISBN 0-201-41663-8Google Scholar
  15. 15.
    Sestoft, P.: Deriving a lazy abstract machine. Journal of Functional Programming 7(3), 231–264 (1997)MATHCrossRefMathSciNetGoogle Scholar
  16. 16.
    Tejfel, M., Horváth, Z., Kozsik, T.: Extending the sparkle core language with object abstraction. Acta Cybernetica 17(2) (2005)Google Scholar
  17. 17.
    Trinder, P.W., Hammond, K., Loidl, H.-W., Jones, S.L.P.: Algorithm + strategy = parallelism. J. Funct. Program. 8(1), 23–60 (1998)MATHCrossRefGoogle Scholar

Copyright information

© Springer-Verlag Berlin Heidelberg 2006

Authors and Affiliations

  • Marko van Eekelen
    • 1
  • Maarten de Mol
    • 1
  1. 1.Institute for Computing and Information SciencesRadboud University NijmegenThe Netherlands

Personalised recommendations