## Type-safe two-level data transformation (2006)

### Cached

### Download Links

- [www.di.uminho.pt]
- [www.di.uminho.pt]
- [repositorium.sdum.uminho.pt]
- [www.di.uminho.pt]
- [www.di.uminho.pt]
- DBLP

### Other Repositories/Bibliography

Venue: | Number 4085 in LNCS |

Citations: | 8 - 7 self |

### BibTeX

@INPROCEEDINGS{Cunha06type-safetwo-level,

author = {Alcino Cunha and José Nuno Oliveira and Joost Visser},

title = {Type-safe two-level data transformation},

booktitle = {Number 4085 in LNCS},

year = {2006},

pages = {284--289},

publisher = {Springer}

}

### OpenURL

### Abstract

Abstract. A two-level data transformation consists of a type-level transformation of a data format coupled with value-level transformations of data instances corresponding to that format. Examples of two-level data transformations include XML schema evolution coupled with document migration, and data mappings used for interoperability and persistence. We provide a formal treatment of two-level data transformations that is typesafe in the sense that the well-formedness of the value-level transformations with respect to the type-level transformation is guarded by a strong type system. We rely on various techniques for generic functional programming to implement the formalization in Haskell. The formalization addresses various two-level transformation scenarios, covering fully automated as well as user-driven transformations, and allowing transformations that are information-preserving or not. In each case, two-level transformations are disciplined by one-step transformation rules and type-level transformations induce value-level transformations. We demonstrate an example hierarchicalrelational mapping and subsequent migration of relational data induced by hierarchical format evolution. Keywords: Two-level transformation, Program calculation, Refinement calculus, Strategic term rewriting, Generalized abstract datatypes, Generic programming,

### Citations

1314 | Introduction to Functional Programming
- Bird, Wadler
- 1988
(Show Context)
Citation Context ...lable statically, though its string representation is available dynamically. 4 For composing partial functions we use the monadic do-notation, exploiting the fact that Maybe is an instance of a Monad =-=[23]-=-. 5 mplus :: Maybe a → Maybe a → Maybe a returns the first argument if it is constructed with Just or the second argument otherwise.sUnleashing composed data migration functions So far, we have develo... |

301 | Functional programming with bananas, lenses, envelopes and barbed wire - Meijer, Fokkinga, et al. - 1991 |

155 | Simple unificationbased type inference for GADTs
- Jones, Vytiniotis, et al.
- 2006
(Show Context)
Citation Context ...sented by the value List Int of type Type [Int ]. The Tag constructor allows us to tag types with names. The datatype Type, adapted from [9], is an example of a generalized algebraic data type (GADT) =-=[24]-=-, a recent Haskell extension that allows to assign more precise types to data constructors by restricting the variables of the datatype in the constructors’ result types. Note also that the argument a... |

136 | Scrap your boilerplate: A practical design pattern for generic programming
- Lämmel, Jones
- 2003
(Show Context)
Citation Context ...ndations. Generic functional programming Type-safe combinators for strategic rewriting were introduced by Lämmel et al in [16], after which several simplified and generalized approaches were proposed =-=[15, 14, 8]-=-. These approaches cover type-preserving transformations (input and output types are the same), and type-unifying ones (all input types mapped to a single output type), but not type-changing ones. Ata... |

85 |
Dynamic Typing in a Statically-Typed Language
- Abadi, Cardelli, et al.
- 1989
(Show Context)
Citation Context ...l, and functions to and from model the value-level transformations that accompany the type-level transformation. Since the equality of two relations is a bi-inclusion we have two readings of equation =-=(1)-=-: idA ⊆ from · to, which ensures that every inhabitant of datatype A has a representation in datatype B; and from · to ⊆ idA, which prevents “confusion” in the transformation process, in the sense tha... |

57 | Typing dynamic typing
- Baars, Swierstra
- 2002
(Show Context)
Citation Context ...6) presented in Figure 1. 3.1 Representation of Types Assume that IN will be represented by Haskell type Int, A ⇀ B by the data type Map a b, and A + B by data Either a b = Left a | Right b. We would =-=(4)-=- (5) (6) (7) (8) (9) (10)sType-safe Two-level Data Transformations 7 add field A Enrichment and removal �� pairwith(b) �� � A × B project �� �� �� �� Generalization and restriction add alternative inj... |

51 | Typed Combinators for Generic Traversal
- Lämmel, Visser
- 2002
(Show Context)
Citation Context ...). Encapsulation of type-changing rewrites Whenever single-step rewrite rules are intended to be applied repeatedly and at arbitrary depths inside terms, it is essential that they are type-preserving =-=[3, 16]-=-. Otherwise, ill-typed terms would be created as intermediate or even as final results. But two-level data transformations are type-changing in general. To resolve this tension, type-changing transfor... |

48 | Wobbly types: type inference for generalised algebraic data types
- Jones, Washburn, et al.
- 2004
(Show Context)
Citation Context ...f integers is represented by the value List Int of type Type [Int ]. The Tag constructor allows us to tag types with names. The datatype Type is an example of a generalized algebraic data type (GADT) =-=[22]-=-, a recent Haskell extension that allows to assign more precise types to data constructors by restricting the variables of the datatype in the constructors’ result types. Note also that the argument a... |

48 | The Under-Appreciated Unfold
- Gibbons, Jones
- 1998
(Show Context)
Citation Context ... in Figure 1. 3.1 Representation of Types Assume that IN will be represented by Haskell type Int, A ⇀ B by the data type Map a b, and A + B by data Either a b = Left a | Right b. We would (4) (5) (6) =-=(7)-=- (8) (9) (10)sType-safe Two-level Data Transformations 7 add field A Enrichment and removal �� pairwith(b) �� � A × B project �� �� �� �� Generalization and restriction add alternative inject A � A + ... |

40 | Scrap your boilerplate” reloaded
- Hinze, Löh, et al.
- 2006
(Show Context)
Citation Context ... term-level, and to this end we need to represent types by terms. Rather than resorting to an untyped universal representation of types, we define the following type-safe representation, adapted from =-=[8]-=-: (3) (4) (5) (6) (7) (8) (9)sadd field A Enrichment and removal �� pairwith(b) �� � A × B project �� �� �� �� Generalization and restriction add alternative inject A � A + B add optional (11) 1 injec... |

38 |
Data refinement by calculation
- Morgan, Gardiner
- 1990
(Show Context)
Citation Context ...s future extensions and applications. 2 Data refinement calculus The theory which underlies our approach to two-level transformations finds its roots in a data refinement calculus which originated in =-=[17, 19, 20]-=-. This calculus has been applied to relational database design [21] reverse engineering of legacy databases [18]. Abstraction and representation Two-level transformation steps are modeled by inequatio... |

33 |
Fun with phantom types
- Hinze
- 2003
(Show Context)
Citation Context ... more precise types to data constructors by restricting the variables of the datatype in the constructors’ result types. Note also that the argument a of the Type datatype is a so-called phantom type =-=[7]-=-, since no value of type a needs to be provided when building a value of type Type a. Using a phantom type we can represent a type at the term level without building any term of that type. (15) (10) (... |

22 | A reification calculus for model-oriented software specification
- Oliveira
- 1990
(Show Context)
Citation Context ...s future extensions and applications. 2 Data refinement calculus The theory which underlies our approach to two-level transformations finds its roots in a data refinement calculus which originated in =-=[17, 19, 20]-=-. This calculus has been applied to relational database design [21] reverse engineering of legacy databases [18]. Abstraction and representation Two-level transformation steps are modeled by inequatio... |

21 | Coupled software transformations (extended abstract
- Lämmel
- 2004
(Show Context)
Citation Context ...ue-level data migration functions. We intend to extend our approach to formalize induction of actual application program transformations, without resorting to wrappers. Coupled transformations Lämmel =-=[11, 10]-=- identifies coupled transformation, where ‘nets’ of software artifacts are transformed simultaneously, as an important research challenge. Format evolution, data-mapping, and co-transformations are in... |

21 | Format Evolution
- Lämmel, Lohmann
- 2001
(Show Context)
Citation Context ...ng language is modified, the source code of existing applications and libraries written in that language must be upgraded to the new language version. These scenarios are examples of format evolution =-=[12]-=- where a data structure and corresponding data instances are transformed in small, infrequent, steps, interactively driven during system maintenance. Similar coupled transformation of data types and c... |

20 |
Software reification using the SETS calculus
- Oliveira
- 1992
(Show Context)
Citation Context ...s future extensions and applications. 2 Data refinement calculus The theory which underlies our approach to two-level transformations finds its roots in a data refinement calculus which originated in =-=[17, 19, 20]-=-. This calculus has been applied to relational database design [21] reverse engineering of legacy databases [18]. Abstraction and representation Two-level transformation steps are modeled by inequatio... |

11 | Inferring type isomorphisms generically
- Atanassow, Jeuring
- 2004
(Show Context)
Citation Context ..., but not type-changing ones. Atanassow et al show how canonical isomorphisms (corresponding to laws for zeros, units, and associativity) between types can induce the value-level conversion functions =-=[2]-=-. They provide an encoding in the polytypic programming language Generic Haskell involving a universal representation of types, and demonstrate how it can be applied to mappings between XML Schema and... |

6 | Back to basics: Deriving representation changers functionally
- Hutton, Meijer
- 1993
(Show Context)
Citation Context ...ns in a typeful and generic manner, poses a challenge for formal reasoning, type systems, and language design.” 7 Such compositions of to and from of different refinements are representation changers =-=[9]-=-.sWe have taken up this challenge by showing that formalization and implementation are feasible. A fully worked out application of our approach in the XML domain can now be attempted. Lämmel et al [13... |

5 | Strategic term rewriting and its application to a VDM-SL to SQL conversion
- Alves, Silva, et al.
- 2005
(Show Context)
Citation Context ...ontext of a local datatype by a composition of such functors, the propagation of two-level transformations from local to global datatype can be derived. Rules for data mapping and format evolution In =-=[1]-=- we presented a set of two-level transformation rules that can be combined with the general laws presented above into a calculator that automatically converts a hierarchic, possibly recursive data str... |

5 | Mappings Make Data Processing Go ’Round
- Lämmel, Meijer
(Show Context)
Citation Context ...re transformed in small, infrequent, steps, interactively driven during system maintenance. Similar coupled transformation of data types and corresponding data instances are involved in data mappings =-=[13]-=-. Such mappings generally occur on the boundaries between programming paradigms, where for example object models, relational schemas, and XML schemas need to be mapped onto each other for purposes of ... |

5 | Strategic polymorphism requires just two combinators
- Lämmel, Visser
- 2002
(Show Context)
Citation Context ...ndations. Generic functional programming Type-safe combinators for strategic rewriting were introduced by Lämmel et al in [16], after which several simplified and generalized approaches were proposed =-=[15, 14, 8]-=-. These approaches cover type-preserving transformations (input and output types are the same), and type-unifying ones (all input types mapped to a single output type), but not type-changing ones. Ata... |

3 | Term rewriting with type-safe traversal functions
- Brand, Klint, et al.
- 2002
(Show Context)
Citation Context ...). Encapsulation of type-changing rewrites Whenever single-step rewrite rules are intended to be applied repeatedly and at arbitrary depths inside terms, it is essential that they are type-preserving =-=[3, 16]-=-. Otherwise, ill-typed terms would be created as intermediate or even as final results. But two-level data transformations are type-changing in general. To resolve this tension, type-changing transfor... |

3 |
Co-transformations in information system reengineering
- Cleve, Henrard, et al.
- 2005
(Show Context)
Citation Context ... et al use the term ‘co-transformation’ for the process of reengineering three kinds of artifacts simultaneously: a database schema, database contents, and application programs linked to the database =-=[4]-=-. Currently, our approach formalizes the use of wrappers for this purpose, where the application program gets preand post-fixed by induced value-level data migration functions. We intend to extend our... |

3 |
et al. Combinators for Bi-Directional Tree Transformations
- Foster
(Show Context)
Citation Context ... Haskell, and avoid the use of a universal representation. Bi-directional programming Foster et al tackle the view-update problem for databases with lenses: combinators for bi-directional programming =-=[6]-=-. Each lens connects a concrete representation C with an abstract view A on it by means of two functions get : C→A and put : A×C→C. Thus, get and put are similar to our from and to, except for put’s a... |

3 | Converting Informal Meta-data to VDM-SL: A Reverse Calculation Approach
- Neves, Silva, et al.
- 1999
(Show Context)
Citation Context ...ansformations finds its roots in a data refinement calculus which originated in [17, 19, 20]. This calculus has been applied to relational database design [21] reverse engineering of legacy databases =-=[18]-=-. Abstraction and representation Two-level transformation steps are modeled by inequations between datatypes and accompanying functions of the following form: A �� to �� � B from Here, the inequation ... |

3 |
Calculate databases with ‘simplicity
- Oliveira
- 2004
(Show Context)
Citation Context ... which underlies our approach to two-level transformations finds its roots in a data refinement calculus which originated in [17, 19, 20]. This calculus has been applied to relational database design =-=[21]-=- reverse engineering of legacy databases [18]. Abstraction and representation Two-level transformation steps are modeled by inequations between datatypes and accompanying functions of the following fo... |

2 |
Type-safe two-level data transformation – with derecursivation and dynamic typing. Accepted for publication
- Cunha, Oliveira, et al.
- 2006
(Show Context)
Citation Context ...can be implemented in a similar way. The only rule that poses a significant technical challenge is rule (9) for recursion elimination. We will only present an outline of our solution (more details in =-=[5]-=-), which uses the Haskell class mechanism and monadic programming. Firstly, we represent the fixpoint operator µ as follows: newtype Mu f = In{out :: f (Mu f )} data Type a where ... Mu :: Dist f ⇒ (∀... |

2 |
Transformations everywhere. Sci. Comput. Program., 52:1–8, 2004. Guest editor’s introduction to special issue on program transformation
- Lämmel
(Show Context)
Citation Context ...ue-level data migration functions. We intend to extend our approach to formalize induction of actual application program transformations, without resorting to wrappers. Coupled transformations Lämmel =-=[11, 10]-=- identifies coupled transformation, where ‘nets’ of software artifacts are transformed simultaneously, as an important research challenge. Format evolution, data-mapping, and co-transformations are in... |

2 | Explosive' Programming Controlled by Calculation - Oliveira - 1998 |

1 |
Data processing by calculation, 2001. 108 pages
- Oliveira
- 2001
(Show Context)
Citation Context ...ry which underlies our approach to two-level transformations finds its roots in a “data refinement” calculus which originated in [19, 20]. This calculus has been applied to relational database design =-=[22, 23]-=- reverse engineering of legacy databases [18]. 2.1 Abstraction and representation Two-level transformation steps are modeled by inequations between datatypes and accompanying functions of the followin... |