Bidirectional transformation has been called lens after Foster et al. (Foster et al., 2007) revisited a classic view updating problem introduced by Bancilhon and Spyratos (Bancilhon and Spyratos, 1981). They has played an important role for maintaining consistency in many fields of applications, database management systems, algebraic data structure interface on programming, and model-driven software development. In particular, lenses are employed in a core foundation of Dejima architecture (Ishihara et al., 2019), distributed systems where data are maintained in different peers, which some parts of data in peers are expect to be synchronized.
A lens is a pair of a forward function and a backward function which are used for maintaining consistency between two related data, a source and a view. Let and be sets of sources and views. The function generates a view from a given source data typically by extracting a part of the source and arranging it in an appropriate way; the function reflects an update on the view with assist of the original source because views have less information than the corresponding sources in general.
To define a meaningful bidirectional transformation, two functions, and , which forms a lens should relate to each other. The relationship is characterized by equations for these functions called lens laws. Figure 1 shows four typical lens laws introduced in (Foster et al., 2007).
The (StrongGetPut) law requires that a source can always be determined by only with an updated view independently of the original source. Under this law, views are as informative as the corresponding sources. The (GetPut) law is a weaker version of the (StrongGetPut) law. This law requires that the same source as original is obtained by whenever the view has not been updated. The (PutGet) law is about consistency of view updating. This law requires that any updated source by with an updated view yields the same view by . The (PutPut) law is a condition imposed only on the function. This law requires that a source updated twice (or possibly more) by with different views consecutively is the same as one obtained by with the last view.
These core lens laws characterize three practical properties on lenses for meaningful bidirectional transformation: bijective, well-behaved, and very-well-behaved. A bijective lens should satisfy the (StrongGetPut) and (PutGet) laws. A well-behaved lens should satisfy the (GetPut) and (PutGet) laws. A very-well-behaved lens should satisfy the (GetPut), (PutGet) and (PutPut) laws. Programmers defining lenses for bidirectional transformation need to select an appropriate property for lenses according to their purpose and application and check if a defined lens satisfies the corresponding lens laws.
One of the solutions is to use domain-specific languages for bidirectional transformation. Many programming languages have been developed to make it easy to define meaningful lenses under specific lens laws (Foster et al., 2007; Ko et al., 2016). They basically give a solution by either permitting to use limited primitives and their combinations or imposing a strong syntactic restriction to write bidirectional programs. If general-purpose languages are used for bidirectional programming, the conformance to the desirable lens laws should be checked for each program. The problem of checking the conformance is, however, in general undecidable because it involves a kind of functional equalities. This is why many bidirectional programming languages have been proposed, where specific lens laws always hold due to a careful design of the languages.
Fischer et al. (Fischer et al., 2015) have shown that weaker lens laws can imply some of the core lens laws which are useful to design bidirectional programming languages. They give a ‘clear picture’ of lens laws where relationship over 9 lens laws shown in Fig. 1 and Fig. 2 except two, (WeakPutGet) and (Undoability), is investigated to show which combination of weaker laws can imply a core law.
Implications among lens laws often help to find their unexpected interaction and give a clear insight to bidirectional transformation. For example, every bijective lens (that satisfies the (StrongGetPut) and (PutGet) laws) is found to be very-well-behaved (that is, to satisfy the (GetPut), (PutGet) and (PutPut) laws) from the facts that the (PutGet) law implies (PutInjectivity) and the conjunction of the (StrongGetPut) and (PutInjectivity) laws implies (PutPut). Fischer et al. introduced several implications to show that a well-behaved lens can be uniquely obtained only from a function as long as satisfies the (PutSurjectivity), (PutTwice) and (PutInjectivity) laws.
A major goal of the present report is to improve Fischer et al.’s clear picture of lens laws. Specifically, we add more two lens laws, (WeakPutGet) and (Undoability), which have been introduced for a practical use (Hidaka et al., 2010; Diskin, 2008; Hidaka et al., 2016) and find all implications among the 11 lens laws to identify an essence of bidirectional transformation. This report describes the following two contributions:
Note that the set of implications introduced in the present report is not shown to be complete in the sense that there may exist an implication among laws which can not be derived from the set. It is left as future work.
As mentioned earlier, the present work is an improvement of a clear picture of lenses introduced by Fischer et al. (Fischer et al., 2015). They give only a few implications among lens laws except (WeakPutGet) and (Undoability). The present report covers much more implications some of which are not trivial.
Hidaka et al. (Hidaka et al., 2016) gives a classification to bidirectional transformation approaches including properties like lens laws required for well-behavedness. They just present the properties independently of each other and do not mention anything about their relationship.
Stevens (Stevens, 2012) gives implications among a few of properties of symmetric lenses, in which sources and views are evenly treated and takes two arguments like . Some of the implications she presents hold also for asymmetric ones as shown in the present report. It would be interesting to consider a complete picture similar to ours for symmetric lens laws.
2. Lens Laws and their Classification
We shall give a brief summary to the 11 lens laws in Fig. 1 and Fig. 2 and show implications among them, e.g., (StrongGetPut) implies (GetPut) and (PutPut) implies (PutTwice). Combining the implications tells us that all the lens laws are classified into three. Except the (WeakPutGet) law, every lens law is weaker than or equal to exactly one of the (StrongGetPut), (PutGet), or (PutPut) laws; the (WeakPutGet) law is strictly weaker than both the (StrongGetPut) and (PutGet) laws. Therefore we classify a set of lens laws into three families according to which of three laws, (StrongGetPut), (PutGet) and (PutPut), implies the law. We call the three families, GetPut, PutGet, and PutPut, respectively. The only (WeakPutGet) law can belong to two families.
In the rest of this report, we write sets of sources and views as and , respectively. We denote by for a set of all possible combinations of and functions, i.e., . For demonstrating examples of lenses, we will use sets , and of integers, non-negative integers and rationals, respectively, and denote by for an element of with and . For , denotes the largest integer less than or equal to . Most of the examples presented here may look elaborate and artificial so as not to satisfies as many other lens laws as possible.
2.1. GetPut Family
The GetPut family consists of six lens laws, (StrongGetPut), (GetPut), (Undoability), (WeakPutGet), (SourceStability), and (PutSurjectivity), all of which are entailment of the (StrongGetPut) law111In this sense, the family might be called StrongGetPut family, though a shorter name is adopted here..
This law indicates that the source is determined only by the view even though the view has less information than the source in general. If the view is given by with a source, then the source is obtained by independently of the original source. Under this law, the function is left-invertible with the function. For example where , a pair of the and functions defined by and satisfies the (StrongGetPut) law.
This law is literally a weakened version of the (StrongGetPut) law. Under this law, the source does not change as long as the view is the same as that obtained by the original source. For example where , a pair of the and functions defined by and satisfies the (GetPut) law but not the (StrongGetPut) law.
This law is literally a weakened version of the (PutGet) law. While the (PutGet) law requires the equality between the view corresponding to the source obtained by an updated view (that is, ) and the updated view (that is, ), the (WeakPutGet) law requires the same equality up to the further operation with the original source. This law is practically important because it allows tentative view updates which may be of an inappropriate form. For example where and , a pair of the and functions defined by and satisfies the (WeakPutGet) law but not the (PutGet) law. Updating a view into with breaks the (PutGet) law because . This law anti-literally belongs to the GetPut family since it is an immediate consequence of the (StrongGetPut) law.
This law implies that any source can be recovered with the view obtained from the source itself no matter how source is updated by a different view. For example where , a pair of the and functions defined by and satisfies the (Undoability) law. Although it has been investigated in a few papers (Diskin, 2008; Foster et al., 2010; Hidaka et al., 2016)222In (Diskin, 2008), a lens is said undoabile when not only (Undoability) but also (PutGet) hold in our terminology., the (Undoability) law is not mentioned even by Fischer et al. (Fischer et al., 2015) where many lens laws are studied. Indeed, this law is the only exception in Fig. 2
that they do not explore. This is probably because it can be easily derived from the(GetPut) and (PutPut) laws. However, we think that the (Undoability) law is one of important lens laws because it is as powerful as the other strong lens laws by combining with weak lens laws as we will see later.
This law requires every source is stable for a certain view. Defining the function that returns the corresponding view for a given source, the pair conforms the (SourceStability) law. For example where , satisfies the (PutTwice) law for which there are infinitary many choices of the function to have the (GetPut) law.
This law requires literally surjectivity of the function.
This law is a weakened version of the (SourceStability) law.
For example where ,
satisfies the (PutSurjectivity) law but not the (SourceStability) law.
The GetPut family makes an implication web as shown in Fig. 3(fig:GetPut) where a double arrow stands for an implication between the two lens laws (e.g., ) and a single arrow from the symbol stands for an implication from the conjunction of the two lens laws connected with to the lens law pointed by the arrow head (e.g., ).
Let us define six classes , , , , , and of lenses as subsets of corresponding six lens laws, e.g., . Then every implication in the figure is shown in the following theorem by an inclusion among lens classes.
Theorem 2.1 ().
The GetPut family has the following inclusions.
Only non-trivial inclusions, (3) and (4), are shown. The inclusion is shown by
The inclusion is shown by
|by (SourceStability) taking such that|
2.2. PutGet Family
The PutGet family consists of four lens laws, (PutGet), (WeakPutGet), (ViewDetermination), and (PutInjectivity), all of which are entailment of the (PutGet) law. Each law is explained here except the (WeakPutGet) law.
This law requires that all information in the updated view is reflected to the source so that the same view can be obtained from it. For example where , a pair of the and functions defined by and satisfies the (PutGet) law.
This law indicates that there is no distinct pair of views which generates the same source by the function. Combining with the (SourceStability) law, it guarantees existence and uniqueness of the function to form a well-behaved lens (Fischer et al., 2015). For example where , satisfies the (ViewDetermination) law.
This law requires literally injectivity of the function for each source fixed. This law guarantees that there is no distinct pair of views which leads the same source for the fixed original source. This law is a weakened version of the (ViewDetermination) law. The three law combination of (PutTwice), (PutSurjectivity) and (PutInjectivity) is equivalent to the two law combination of (SourceStability) and (ViewDetermination) (Fischer et al., 2015). For example where , satisfies the (PutInjectivity) law but violates the (ViewDetermination) law.
The PutGet family makes an implication web as shown in Fig. 3(fig:PutGet). Let us define classes , , and of lenses in a similar way to those of the GetPut family. Every implication in the figure is shown in the following theorem.
Theorem 2.2 ().
The PutGet family has three inclusions.
Both inclusions, (1) and (2), are trivial. For (3), suppose that the (PutInjectivity) and (WeakPutGet) laws hold. Then we have because of the (WeakPutGet) law. This equation implies by the (PutInjectivity) law, hence we have the (PutGet) law. ∎
2.3. PutPut Family
The PutPut family consists of two lens laws, (PutPut) and (PutTwice), which forms a single entailment of the (PutPut) law.
This law requires that the source obtained by repeatedly applying the functions with many views is the same as that obtained by a single application with the last view. It plays an important role for state-based lenses, that is, the history of updates can always be ignored. For example where , satisfies the (PutPut) law.
This law imposes ‘idempotency’ of the function applied with the fixed view. This law is obviously a weakened version of the (PutPut) law. For example where , satisfies the (PutTwice) law but violates the (PutPut) law).
The PutPut family makes a simple implication web as shown in Fig. 3(fig:PutPut). Let us define two classes and of lenses in a similar way to those of the GetPut family. The implication in this family is shown in the following theorem whose proof is straightforward.
Theorem 2.3 ().
The PutPut family has an inclusion.
3. Association beyond Families
We have seen that a single lens law does not entail any lens law in the different family except for the case involving the (WeakPutGet) law. In this section, we investigate inclusions of the form beyond families. Specifically, possible inclusions of this form are presented where either (a) and belong to the same family or (b) , and belong to different families each other. All of those inclusions are proper although their proofs are omitted in the present report.
3.1. Equivalence under Another Law
First, possible implications of the form are studied where and belong to the same family and . This type of inclusions indicates that and are equivalent within , i.e., .
In the GetPut family, an inclusion of this type is found.
Theorem 3.1 ().
The following inclusion holds.
Suppose that the (PutSurjectivity) and (PutTwice) laws hold. For , (PutSurjectivity) gives and such that . Then we have
hence the (SourceStability) law holds taking . ∎
This inclusion gives an equivalence relation in the GetPut family under a lens law belonging to another family, that is,
The following theorem shows a inclusion where two lens classes in the GetPut family are involved as well as the above but those two are not related by inclusion. Nevertheless it leads their equivalence under another lens laws in a different family as we will see later.
Suppose that the (GetPut) and (PutPut) laws hold. Then we have the (Undoability) law because
This theorem leads equivalence of the (GetPut) and (Undoability) laws under (PutPut) law as follows:
|by Theorem 3.2|
|by Theorem 2.1(2) and Theorem 2.3|
|by Theorem 3.1 and Theorem 2.1(3)|
|by Theorem 2.1(4)|
which indicates .
In the PutGet family, three inclusions of the form are presented where and belong to the PutGet family and .
Theorem 3.3 ().
The following inclusions hold.
For (1), suppose that the (ViewDetermination) and (GetPut) laws hold. By the (GetPut) law, we have . Since this equation implies by the (ViewDetermination) law, we have the (PutGet) law.
For (2), suppose that the (PutInjectivity) and (PutTwice) laws hold. When , we have
|by the assumption|
|by the assumption|
This equation implies by the (PutInjectivity) law, hence we have the (ViewDetermination) law. ∎
These inclusions makes two or three laws in the PutGet family equivalent under another law in a different family:
3.2. Implication of Combination
Next, possible implications of the form are studied where , and belong to different families. Two inclusions of this type are found.
Theorem 3.4 ().
The following inclusions hold.
For (1), suppose that the (SourceStability) and (ViewDetermination) holds. By the (SourceStability) law, we take such that . This equation implies by the (ViewDetermination) law. Then we have
which indicates the (PutTwice) law.
For (2), suppose that the (StrongGetPut) and (PutInjectivity) laws hold. By the (StrongGetPut) law, we have
By applying the (PutInjectivity) law to this equation, we have . Then the (PutPut) law holds because
|by the equation.|
3.3. Summary of Implications
Combining all implication theorems shown in the present report, we have a big web structure among 11 lens laws as shown in Fig. 4. This figure tells not only implications but equalities among lens laws and their conjunctions.
For example, the equivalence relation shown in (Fischer et al., 2015, Theorem 2),
can be concluded from this figure by checking that the conjunction of the (SourceStability) and (ViewDetermination) laws entails the (PutSurjectivity), (PutTwice), and (PutInjectivity), and vice versa.
For another example, any lens satisfying the (WeakPutGet), (SourceStability), and (ViewDetermination) laws can be found to be well-behaved because the figure leads to the (GetPut) and (PutGet) laws from the three laws. This holds even when the (PutInjectivity) law instead of (ViewDetermination).
4. Concluding Remark
A precise relationship among lens laws has been presented. Eleven lens laws which has been introduced in the literature on bidirectional transformation are found to relate to each other, one implies another and a combination of two implies another. The implication graph which shows all the relationship might be helpful to check lens laws and certify properties for a given bidirectional transformation.
Our goal is to give a ‘complete picture’ of lens laws from which we can derive all possible implications of the form with classes , …, and of lens laws. To achieve the goal, it would be shown that every implication of the form which cannot be obtained from the implication graph has a counterexample. The complete picture will help us to understand the essence of bidirectional transformation.
- Bancilhon and Spyratos (1981) François Bancilhon and Nicolas Spyratos. 1981. Update Semantics of Relational Views. ACM Trans. Database Syst. 6, 4 (1981), 557–575.
- Diskin (2008) Zinovy Diskin. 2008. Algebraic Models for Bidirectional Model Synchronization. In Model Driven Engineering Languages and Systems, 11th International Conference, MoDELS 2008, Toulouse, France, September 28 - October 3, 2008. Proceedings. Springer, 21–36.
- Fischer et al. (2015) Sebastian Fischer, Zhenjiang Hu, and Hugo Pacheco. 2015. A Clear Picture of Lens Laws - Functional Pearl. In Mathematics of Program Construction - 12th International Conference, MPC 2015, Königswinter, Germany, June 29 - July 1, 2015. Proceedings. Springer, 215–223.
- Foster et al. (2007) J. Nathan Foster, Michael B. Greenwald, Jonathan T. Moore, Benjamin C. Pierce, and Alan Schmitt. 2007. Combinators for bidirectional tree transformations: A linguistic approach to the view-update problem. ACM Trans. Program. Lang. Syst. 29, 3 (2007), 17.
- Foster et al. (2010) Nate Foster, Kazutaka Matsuda, and Janis Voigtländer. 2010. Three Complementary Approaches to Bidirectional Programming. In Generic and Indexed Programming - International Spring School, SSGIP 2010, Oxford, UK, March 22-26, 2010, Revised Lectures. Springer, 1–46.
- Hidaka et al. (2010) Soichiro Hidaka, Zhenjiang Hu, Kazuhiro Inaba, Hiroyuki Kato, Kazutaka Matsuda, and Keisuke Nakano. 2010. Bidirectionalizing graph transformations. In Proceeding of the 15th ACM SIGPLAN international conference on Functional programming, ICFP 2010, Baltimore, Maryland, USA, September 27-29, 2010. 205–216.
- Hidaka et al. (2016) Soichiro Hidaka, Massimo Tisi, Jordi Cabot, and Zhenjiang Hu. 2016. Feature-based classification of bidirectional transformation approaches. Software and System Modeling 15, 3 (2016), 907–928.
- Ishihara et al. (2019) Yasunori Ishihara, Hiroyuki Kato, Keisuke Nakano, Makoto Onizuka, and Yuya Sasaki. 2019. Toward BX-Based Architecture for Controlling and Sharing Distributed Data. In IEEE International Conference on Big Data and Smart Computing, BigComp 2019, Kyoto, Japan, February 27 - March 2, 2019. 1–5.
- Ko et al. (2016) Hsiang-Shang Ko, Tao Zan, and Zhenjiang Hu. 2016. BiGUL: a formally verified core language for putback-based bidirectional programming. In Proceedings of the 2016 ACM SIGPLAN Workshop on Partial Evaluation and Program Manipulation, PEPM 2016, St. Petersburg, FL, USA, January 20 - 22, 2016. 61–72.
- Stevens (2012) Perdita Stevens. 2012. Observations relating to the equivalences induced on model sets by bidirectional transformations. ECEASST 49 (2012).