Epigram: practical programming with dependent types

  • Authors:

  • Conor McBride

  • Affiliations:

  • School of Computer Science and Information Technology, University of Nottingham, Nottingham, United Kingdom

  • Venue:
  • AFP'04 Proceedings of the 5th international conference on Advanced Functional Programming
  • Year:
  • 2004

Quantified Score

Hi-index 0.00

Visualization

Abstract

Find the type error in the following Haskell expression: if null xs then tail xs else xs You can’t, of course: this program is obviously nonsense unless you’re a typechecker. The trouble is that only certain computations make sense if the null xs test is True, whilst others make sense if it is False. However, as far as the type system is concerned, the type of the then branch is the type of the else branch is the type of the entire conditional. Statically, the test is irrelevant. Which is odd, because if the test really were irrelevant, we wouldn’t do it. Of course, tail [] doesn’t go wrong—well-typed programs don’t go wrong—so we’d better pick a different word for the way they do go. Abstraction and application, tupling and projection: these provide the ‘software engineering’ superstructure for programs, and our familiar type systems ensure that these operations are used compatibly. However, sooner or later, most programs inspect data and make a choice—at that point our familiar type systems fall silent. They simply can’t talk about specific data. All this time, we thought our programming was strongly typed, when it was just our software engineering. In order to do better, we need a static language capable of expressing the significance of particular values in legitimizing some computations rather than others. We should not give up on programming.