Results 1  10
of
18
A Language for Generic Programming
, 2005
"... First and foremost I thank my parents for all their love and for teaching me to enjoy learning. I especially thank my wife Katie for her support and understanding through this long and sometimes stressful process. I also thank Katie for insisting on good error messages for G! My advisor, Andrew Lums ..."
Abstract

Cited by 19 (3 self)
 Add to MetaCart
(Show Context)
First and foremost I thank my parents for all their love and for teaching me to enjoy learning. I especially thank my wife Katie for her support and understanding through this long and sometimes stressful process. I also thank Katie for insisting on good error messages for G! My advisor, Andrew Lumsdaine, deserves many thanks for his support and guidance and for keeping the faith as I undertook this long journey away from scientific computing and into the field of programming languages. I thank my thesis committee: R. Kent Dybvig, Daniel P. Friedman, Steven D. Johnson, and Amr Sabry for their advice and encouragement. A special thanks goes to Ronald Garcia, Christopher Mueller, and Douglas Gregor for carefully editing and catching the many many times when I accidentally skipped over the important stuff. Thanks to Jaakko and Jeremiah for hours of stimulating discussions and arguments concerning separate compilation and conceptbased overloading. Thanks to David Abrahams for countless hours spent debating the merits of one design over another while jogging through the hinterlands of Norway. Thanks to Alexander Stepanov and David Musser for getting all this started, and thank you for the encouragement over the years. Thanks to Matthew Austern, his book Generic Programming in the STL was both an inspiration
Implementing Polymorphism in SMT solvers ∗
"... Based on our experience with the development of AltErgo, we show a small number of modifications needed to bring parametric polymorphism to our SMT solver. The first one occurs in the typing module where unification is now necessary for solving polymorphic constraints over types. The second one con ..."
Abstract

Cited by 15 (1 self)
 Add to MetaCart
(Show Context)
Based on our experience with the development of AltErgo, we show a small number of modifications needed to bring parametric polymorphism to our SMT solver. The first one occurs in the typing module where unification is now necessary for solving polymorphic constraints over types. The second one consists in extending triggers ’ definition in order to deal with both term and type variables. Last, the matching module must be modified to account for the instantiation of type variables. We hope that this experience is convincing enough to raise interest for polymorphism in the SMT community. 1
Types for UnitsofMeasure: Theory and Practice
"... Unitsofmeasure are to science what types are to programming. In science and engineering, dimensional and unit consistency provides a first check on the correctness of an equation or formula, just as in programming the validation of a program by the typechecker eliminates one possible reason for f ..."
Abstract

Cited by 8 (1 self)
 Add to MetaCart
(Show Context)
Unitsofmeasure are to science what types are to programming. In science and engineering, dimensional and unit consistency provides a first check on the correctness of an equation or formula, just as in programming the validation of a program by the typechecker eliminates one possible reason for failure.
Inferable ObjectOriented Typed Assembly Language
"... A certifying compiler preserves type information through compilation to assembly language programs, producing typed assembly language (TAL) programs that can be verified for safety independently so that the compiler does not need to be trusted. There are two challenges for adopting certifying compil ..."
Abstract

Cited by 4 (2 self)
 Add to MetaCart
(Show Context)
A certifying compiler preserves type information through compilation to assembly language programs, producing typed assembly language (TAL) programs that can be verified for safety independently so that the compiler does not need to be trusted. There are two challenges for adopting certifying compilation in practice. First, requiring every compiler transformation and optimization to preserve types is a large burden on compilers, especially when adopting certifying compilation into existing optimizing noncertifying compilers. Second, type annotations significantly increase the size of assembly language programs. This paper proposes an alternative to traditional certifying compilers. It presents iTalX, the first inferable TAL type system that supports existential types, arrays, interfaces, and stacks. We have proved our inference algorithm is complete, meaning if an assembly
QML: Explicit FirstClass Polymorphism for ML
"... Recent years have seen a revival of interest in extending ML’s predicative type inference system with impredicative quantification in the style of System F, for which type inference is undecidable. This paper suggests a modest extension of ML with System F types: the heart of the idea is to extend t ..."
Abstract

Cited by 2 (0 self)
 Add to MetaCart
Recent years have seen a revival of interest in extending ML’s predicative type inference system with impredicative quantification in the style of System F, for which type inference is undecidable. This paper suggests a modest extension of ML with System F types: the heart of the idea is to extend the language of types with unary universal and existential quantifiers. The introduction and elimination of a quantified type is never inferred but indicated explicitly by the programmer by supplying the quantified type itself. Quantified types coexist with ordinary ML schemes, which are in turn implicitly introduced and eliminated at letbindings and use sites, respectively. The resulting language, QML, does not impose any restriction on instantiating quantified variables with quantified types; neither let nor λbound variables ever require a type annotation, even if the variable’s inferred scheme or type involves quantified types. This proposal, albeit more verbose in terms of annotations than others, is simple to specify, implement, understand, and formalize.
Theoretical Foundations for Practical ‘Totally Functional Programming’
, 2007
"... Interpretation is an implicit part of today’s programming; it has great power but is overused and has
significant costs. For example, interpreters are typically significantly hard to understand and hard
to reason about. The methodology of “Totally Functional Programming” (TFP) is a reasoned
attempt ..."
Abstract
 Add to MetaCart
Interpretation is an implicit part of today’s programming; it has great power but is overused and has
significant costs. For example, interpreters are typically significantly hard to understand and hard
to reason about. The methodology of “Totally Functional Programming” (TFP) is a reasoned
attempt to redress the problem of interpretation. It incorporates an awareness of the undesirability
of interpretation with observations that definitions and a certain style of programming appear to
offer alternatives to it. Application of TFP is expected to lead to a number of significant outcomes,
theoretical as well as practical. Primary among these are novel programming languages to lessen or
eliminate the use of interpretation in programming, leading to betterquality software. However,
TFP contains a number of lacunae in its current formulation, which hinder development of these
outcomes. Among others, formal semantics and typesystems for TFP languages are yet to be
discovered, the means to reduce interpretation in programs is to be determined, and a detailed
explication is needed of interpretation, definition, and the differences between the two. Most
important of all however is the need to develop a complete understanding of the nature of
interpretation. In this work, suitable typesystems for TFP languages are identified, and guidance
given regarding the construction of appropriate formal semantics. Techniques, based around the
‘fold’ operator, are identified and developed for modifying programs so as to reduce the amount of
interpretation they contain. Interpretation as a means of languageextension is also investigated.
v
Finally, the nature of interpretation is considered. Numerous hypotheses relating to it considered in
detail. Combining the results of those analyses with discoveries from elsewhere in this work leads
to the proposal that interpretation is not, in fact, symbolbased computation, but is in fact something
more fundamental: computation that varies with input. We discuss in detail various implications of
this characterisation, including its practical application. An often moreuseful property, ‘inherent
interpretiveness’, is also motivated and discussed in depth. Overall, our inquiries act to give
conceptual and theoretical foundations for practical TFP.
ProjectTeam Gallium Programming languages, types, compilation and proofs
"... e p o r t ..."
(Show Context)
Size Calculus for a HigherOrder Functional Language
"... Abstract. The authors present a lambdacalculus that formalizes the relations between the sizes of arguments and the sizes of the corresponding results of functions in a higherorder polymorphic functional language. On top of usual constructions two operators for finite maps: List, that defines (h ..."
Abstract
 Add to MetaCart
(Show Context)
Abstract. The authors present a lambdacalculus that formalizes the relations between the sizes of arguments and the sizes of the corresponding results of functions in a higherorder polymorphic functional language. On top of usual constructions two operators for finite maps: List, that defines (higherorder) finite maps, and Shift are considered. Intuitively, size expressions are abstract interpretations of programs in the natural arithmetic. To prove normalization and diamond (modulo integer axiomatics) property of the calculus we show that the calculus can be expressed in System F. 1