Transporting functions across ornaments

Abstract

Programming with dependent types is a blessing and a curse. It is a blessing to be able to bake invariants into the definition of datatypes: we can finally write correct-by-construction software. However, this extreme accuracy is also a curse: a datatype is the combination of a structuring medium together with a special purpose logic. These domain-specific logics hamper any effort of code reuse among similarly structured data. In this paper, we exorcise our datatypes by adapting the notion of ornament to our universe of inductive families. We then show how code reuse can be achieved by ornamenting functions. Using these functional ornament, we capture the relationship between functions such as the addition of natural numbers and the concatenation of lists. With this knowledge, we demonstrate how the implementation of the former informs the implementation of the latter: the user can ask the definition of addition to be lifted to lists and she will only be asked the details necessary to carry on adding lists rather than numbers. Our presentation is formalised in a type theory with a universe of datatypes and all our constructions have been implemented as generic programs, requiring no extension to the type theory.

Foundations of dependent interoperability

“…Functional ornaments. To remediate these limitations, the notion of functional ornaments (Dagand & McBride, 2012) was developed. As for ornaments, functional ornaments aim at transporting functions from simple, non-indexed types to more precise, indexed types.…”

A principled approach to ornamentation in ML

“…In the case of strictly positive datatypes and first-order functions, this result can be translated to the coherence property of ornaments [Dagand and McBride 2014]. We can define a projection function that projects the whole datatype at once (rather than incrementally as with the proj function), e.g.…”

“…Programming with generalized algebraic datatypes (GADT) requires writing multiple definitions of the same type holding different invariants. GADT definitions that only add constraints could be considered ornaments of regular types, which was one of the main motivations for introducing ornaments in the first place [Dagand and McBride 2014]. It would then be useful to automatically derive, whenever possible, copies of the functions on the original type that preserve the new invariants.…”

Programming with ornaments

“…Gap 3 (interactive support for constructing of ornaments and ornamental descriptions) Both Dagand & McBride (2014) and Williams et al (2014) propose concrete syntax for defining ornamental descriptions, and Williams et al also devise an "ornament from" mechanism for defining ornaments (between two existing datatypes, rather than creating a new datatype on top of an existing one) in terms of forgetful functions, which should conform to some syntax restrictions. We have shown that the construction of ornaments (and ornamental descriptions) can be performed in an interactive manner, so perhaps ornaments can also be constructed in a special tactic language, in which the programmer can go through the interactive construction process by giving instructions linking two existing datatype declarations, and get valid ornaments by construction.…”

“…McBride's work spawned a number of subsequent developments: The ornament-induced forgetful function was extended by Ko & Gibbons (2013a) to an isomorphism for promoting less informative datatypes to more informative ones; at the heart of the construction of the promotion isomorphism is a parallel composition operation on ornaments that, in general, can be used to combine multiple constraints on a datatype and synthesise a new variant of the datatype with all those constraints embedded at once. Dagand & McBride (2014) then proposed functional ornaments, generalising ornaments to work also for functions. Algebraic ornamentation has also been generalised to a relational setting, and shown to work with relational calculation techniques (Ko & Gibbons, 2013b).…”