Epigram: Practical Programming with Dependent Types Export

@incollection{mcbride:eppwdt, abstract = {Find the type error in the following Haskell expression: 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, 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.}, author = {Mcbride, Conor}, citeulike-article-id = {2247480}, citeulike-linkout-0 = {http://dx.doi.org/10.1007/11546382_3}, doi = {10.1007/11546382_3}, journal = {Advanced Functional Programming}, keywords = {dependent-types, epigram, functional-programming}, pages = {130--170}, posted-at = {2008-11-18 13:08:58}, priority = {2}, title = {Epigram: Practical Programming with Dependent Types}, url = {http://dx.doi.org/10.1007/11546382_3}, year = {2005} }

TY - CHAP ID - mcbride:eppwdt L3 - citeulike-article-id:2247480 N2 - Find the type error in the following Haskell expression: 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, 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. JF - Advanced Functional Programming EP - 170 TI - Epigram: Practical Programming with Dependent Types SP - 130 KW - dependent-types KW - epigram KW - functional-programming AU - Mcbride, Conor PY - 2005/// UR - http://dx.doi.org/10.1007/11546382_3 ER -