DMCA
Inductive families need not store their indices (2004)
| Venue: | Types for Proofs and Programs, Torino, 2003, volume 3085 of LNCS |
| Citations: | 46 - 16 self |
BibTeX
@INPROCEEDINGS{Brady04inductivefamilies,
author = {Edwin Brady and Conor Mcbride and James Mckinna},
title = {Inductive families need not store their indices},
booktitle = {Types for Proofs and Programs, Torino, 2003, volume 3085 of LNCS},
year = {2004},
pages = {115--129},
publisher = {Springer-Verlag}
}
Share
 |
 |
 |
 |
||
OpenURL
Abstract
Abstract. We consider the problem of efficient representation of dependently typed data. In particular, we consider a language TT based on Dybjer's notion of inductive families [11] and reanalyse their general form with a view to optimising the storage associated with their use. We introduce an execution language, ExTT, which allows the commenting out of computationally irrelevant subterms and show how to use properties of elimination rules to elide constructor arguments and tags in ExTT. We further show how some types can be collapsed entirely at run-time. Several examples are given, including a representation of the simply typed *-calculus for which our analysis yields an 80 % reduction in run-time storage requirements. 1 Introduction Dependent type theory provides programmers with more than an integrated logic for reasoning about program correctness. It allows more precise types for programs and data in the first place, strengthening the typechecker's language of guarantees. We have richer function types 8x: S: T which adapt their return types to each argument; we also have richer data structures which do not just contain but explain data, exposing and enforcing their properties. Moreover, we may reasonably expect more static detail about programs and data to yield better optimised dynamic behaviour. We need neither test what is guaranteed nor store what is determined by typechecking. Pollack's implicit syntax [24] already supports the omission of much redundant information from concrete syntax for similar reasons.
Keyphrases
inductive family execution language dynamic behaviour much redundant information implicit syntax introduction dependent type theory function type irrelevant subterms integrated logic general form elimination rule static detail constructor argument language tt analysis yield run-time storage requirement return type data structure precise type first place several example typed calculus efficient representation program correctness similar reason concrete syntax
