DELIMITACIÓN CONCEPTUAL DEL COMPROMISO ORGANIZACIONAL EN EL

Recall from Chapter 2 that a state-based symmetric lens ` between sets X and Y

comprises a set of complements C, a distinguished element missing ∈ C, and two

functions

putr ∈ X×C →Y ×C putl ∈ Y ×C →X×C

satisfying some round-tripping laws. Now, for any set X we have the monoid OX whose elements (edits) are lists of overwriting elements of X modulo the equality xx = x. An action of OX on X is defined by hix = x and hx, wi y = x where

x ∈ X, w ∈ X?_{. Note that this is well defined as x(xy) = x = xy. If, in addition,} we have a distinguished element x∈X, we thus obtain a module denoted Xx where

|Xx|=X and initX =x and ∂Xx =OX.

We are now ready to give the definition of the lifting operation that turns any symmetric, state-based lens between inhabited types into a symmetric edit lens.9

`∈X ↔ s Y x∈X `.putr(x, `.missing) = (y, c0) ∂x`∈Xx ↔Yy C = `.C missing = c0 K = {(x, c, y)|`.putr(x, c) = (y, c)} Vg = `.putr Wg = `.putl

∂x` is a symmetric edit lens and the passage from ` to ∂x` is compatible with the equivalences on symmetric lenses and symmetric edit lenses. The equations forVand W are well-defined because the round-trip law for symmetric lenses guarantees that

putting the same value twice in a row results in the same output both times (hence if edits will be coalesced in Xx, they will be translated to edits that get coalesced in

Yy), and the consistency relation is likewise preserved because the roundtrip laws for symmetric lenses guarantee that any given putr or putl results in a “stable state”.

3.6.1 Theorem: If k and ` are state-based lenses and k ≡`, then ∂xk ≡∂x`.

Proof: Suppose S is a witness that k≡`. Then we define ∂xS as follows:

∂xS ={(x, ck, c`, y)|(ck, c`)∈S∧x∈X∧y∈Y}

Let us write (yk, c0k) = k.putr(x, k.missing) and (y`, c0`) = `.putr(x, `.missing). Since (k.missing, `.missing) ∈ S, we know yk = y` and (c0k, c0`) ∈ S. The former equality tells us that at least the two lenses have the same type—that is, Yyk =Yy`

as modules—while the latter inclusion lets us observe that

(initXx,(∂xk).missing,(∂x`).missing,initYy) = (x, k.missing, `.missing, y)∈∂xS

where we abbreviate yk and y` by the name y.

9_{The unique state-based lens between uninhabited types can be lifted to the unique edit lens}

It remains to show that ∂xS is preserved by V and W (definedness is not in question since the modules in question have no partial edits); these arguments are very similar, so we focus on the one forV. We have x0 ∈X, y0 ∈Y,(ck, c`)∈S,dx∈Xx. We must show that computingVwith these values produces values that form a tuple

in∂xS. We proceed by induction on dx.

In case dx=hi, we are done: after computing _V, we still havex0, y0,ck, and c`. Otherwise, dx=x1:dx0 and the induction hypothesis tells us that if the two equations

(∂xk).V(dx0, ck) = (dyk, c0k)

(∂x`).V(dx0, c`) = (dy`, c0`)

hold then (c0_k, c0<sub>`</sub>) ∈S and dyk =dy`. We can then conclude that if k.putr(x1, c0k) =

(yk, c00k) and `.putr(x1, c0`) = (y`, c00`) then yk = y` and (c00k, c 00

`) ∈ S because S is a witness that k ≡ `. We now compute with these definitions that (∂xk).V(dx, ck) =

(yk:dyk, c00k)and(∂x`).V(dx, c`) = (y`:dy`, c`00). But we have already seen thatyk:dyk=

y`:dy` and (c00k, c00`)∈S, so we are done.

Let X be a module. A differ for X is a binary operation dif ∈ |X| × |X| → ∂X

satisfying dif(x, x0)x = x0 and dif(x, x) = 1. (The edit dif(x, x0) is permitted to

be partial everywhere except x.) Thus, a differ finds, for given states x, x0, an edit

operation dx such that dx x =x0 and dx is “reasonable” at least in the sense that if x=x0 then the produced edit is minimal, namely1. For example, the moduleXx for set X and x ∈ X admits the canonical differ given by dif(x, x0) =x0 if x 6= x0 and dif(x, x) = 1, otherwise.

Given an edit lens ` between modules X and Y, both equipped with differs, we

define a symmetric lens |`|. The passage ` 7→ |`| is compatible with lens equivalence.

` ∈X ↔Y

|`| ∈ |X| ↔

s |Y|

C = |X| ×`.C× |Y|

missing = (initX, `.missing,initY)

putr(x,(x0, c, y0)) = (dy y0,(x, c0,dy y0))

where(dy, c0) =`._V(dif(x0, x), c) putl(y,(x0, c, y0)) analogous

3.6.2 Theorem: Let X, Y be sets with distinguished elements x and y and equip

the associated modulesXx and Yy with their canonical differs. The constructions| − | and∂x then establish a one-to-one correspondence between equivalence classes of edit lenses between Xx and Yy, on the one hand, and state-based lenses between X and

Proof: Let ` be a state-based lens between sets X and Y and let x ∈ X, y ∈ Y

satisfy `.putr(x, `.missing) = (y, `.missing). To show that |∂x`| ≡ ` we use the simulation R={((x, c, y), c)|`.putr(x, c) = (y, c)}. Conversely, if `∈ Xx ↔Yy then

` ≡ ∂initX|`|. To see this, we use the simulation S = {(x, c,(x, c, y), y) | x ∈ X, y ∈

Y, c∈`.C}. We omit the verification of both simulations.

The theorem’s condition that (x, `.missing, y) already be a consistent triple may

look strong at first, but one can simply take an arbitrary lens and “step” it once byx

(producing a new lens whose missing component is given byputr) to produce a lens

with essentially the same behavior but a stable missing component. We conjecture

that this “isomorphism” between state-based and certain edit lenses is also compatible with various lens constructors, in particular tensor product and sum.

3.7

Conclusion

Recall from Chapter 1 that there are four high-level challenges in the design of bidi- rectional programming languages: alignment, symmetry, performance, and syntax. The tools from Chapter 2—existentially quantified complement sets and an equiv- alence relation to quotient out uninteresting differences between them—enabled a symmetric system that nevertheless supports a range of useful transformations. This chapter’s approach retains those tools while tackling the remaining two challenge ar- eas of alignment and performance. We identified an abstract model for edits and edit transformations—monoids and monoid homomorphisms, respectively—and investi- gated instantiations of these models to the standard basic data types and operations. In our investigation, we showed that the natural instantiations (in particular our list and container edit monoids) enable rich alignment information to be provided to, pro- cessed by, and received from our transformations. Moreover, our lens transformations traverse edits and complements, but not repositories. Because our instantiations of edit monoids contain significantly less data than the repositories (and complements are typically trivial or at most represent the spine of the data), traversals of these data should require less processing power, memory, and transmission bandwidth. View- ing edits as a compression scheme for updated repositories, we have shown that edit lenses can compute on the compressed data directly without decompressing; this is a significant proof burden for other compression techniques. We have shown that these techniques for alignment representation and processing efficiency are applicable within the realm of symmetric lenses and compatible with most of the transformations needed for a comprehensive syntax of edit lenses.

Chapter 4

Prototype Library for Edit Lenses

4.1

Introduction

Having developed the theory of lenses and instantiating the framework with a syntax, we now give an exposition on preliminary efforts to instantiate the syntax as a concrete program. Our work on a prototype has two main purposes. The edit lens framework is predicated on a relatively abstract, algebraic data model, whereas long-term data storage on computers typically employs a fairly low-level model based on strings. When only the data is important, these two realms are usually connected by defining a parser that processes strings and produces a more structured representation, as well as a formatter that produces a string representation of a given structure. For edit lenses, however, not only the data is important; one also wants access to the edits made to the data. So the primary goal is to investigate what extensions are needed to describe the connection between edits to strings and edits to structured data. A secondary goal is to validate that the fundamental edit lens design is complete; producing a few example transformations gives an opportunity for any unforeseen infelicities to manifest. In the pursuit of these goals, we discuss two artifacts: first, a core library which closely models the edit lens theory given in Chapter 3; and second, a demonstration program that synchronizes two simple, text-based databases according to a predetermined lens. Creating the demonstration program involved building a text-editing GUI, connecting the lens to the GUI, and validating and extracting edits from user actions. All of these tasks fall outside the realm of the existing edit lens theory.

We have chosen to implement our demo in Haskell, a language which encourages high abstraction levels, supports rapid prototyping, and has good library support. Be- cause one of our primary goals was experimentation, we wanted to retain a lightweight approach throughout; in particular we chose not to begin with a mechanization of the theory in a dependently-typed language. While avoiding the need for proofs sig- nificantly reduced the implementation effort, several implementation details would have been more naturally expressed in a dependent language: instances of container

types are dependent pairs of a shape and a function whose domain is that shape, and module types are essentially dependent functions which take a value and produce the type of the module with that value as its init field. We also investigated extend-

ing Boomerang [9], an existing asymmetric, state-based string lens implementation. Boomerang is very complete, and consequently would have required many tangen- tial coding efforts; to avoid distractions, we chose to take a less feature-complete route. However, we retained Boomerang’s choice of string-based data model since, as discussed above, this closely matches real-world scenarios.

Several Haskell packages offer implementations of asymmetric, state-based lenses, typically with the goal of providing an improved alternative syntax for Haskell’s built- in mechanisms for updating complicated data structures. The largest one,lens [34],

has found wide use in a variety of applications, and is intended to be a one-stop library for modifying data, includes an enormous array of utilities, including many useful operations which do not at first glance appear related to asymmetric, state-based lenses. It has been developed by a large team of volunteers over several years, resulting in tens of thousands of lines of code. In contrast, the demonstration discussed here was developed by a single researcher over the course of several months, so its goals and scope are necessarily more focused. In particular, we do not try to match the breadth of lens and lens combinators provided by lens, though our lenses do offer

additional capabilities for parsing, serialization, and edit discovery.

Indeed, supporting edit discovery is our primary challenge. We will discuss this problem in detail below; in short, it is an edit-based analog to the problem of parsing. With edit lenses, there are always two domains of discourse: the collection of reposi- tories and the collection of edits. Repositories store ordinary data, and the problem of connecting strings with structured data is well-studied under the umbrella of pars- ing. (Turning structured data into a string—often called serialization—is typically a significantly simpler task.) However, standard parsing techniques—even incremental techniques purportedly designed for making it easy to maintain a correct parse tree in the presence of ongoing updates—do not adequately describe the connection between string modifications and edits in the sense described in Chapter 3. One could avoid the situation entirely by designing a structured editor. Historically, though, struc- tured editors have failed to take—perhaps because their strictures are too confining for day-to-day editing tasks—so we chose to avoid this route. Below, we propose heuristics that seem to behave acceptably in a number of standard cases. Though they are somewhat tailored to the file format under consideration here and reflect some unusual user actions as edits with slightly different meanings, they nevertheless enable an editor with none of the restrictions traditionally associated with structured editors.

(a) An initial pair of databases in two text editing panes.

(b) Inserting Mozart on the right in- troduces default data on the left.

(c) Deleting Haydn from one side is reflected to the other automatically.

(d) A default country is used for the new row on the right.

(e) Correcting Haydn’s country has no effect on the birth year list. . .

(f) . . . but correcting the spelling of Haydn in either list corrects both.

(g) More bizarre edits, like this dele- tion that spans records. . .

(h) . . . reset the alignment, but only for the affected records.