Robust Projectional EditingFriedrich Steimann

Fernuniversitat in Hagensteimann@acm.org

Marcus FrenkelFernuniversitat in Hagenmarcus.frenkel@feu.de

Markus Volterindependent/itemis AG

voelter@acm.org

AbstractWhile contemporary projectional editors make sure that theedited programs conform to the programming language’smetamodel, they do not enforce that they are also well-formed, that is, that they obey the well-formedness rules de-�ned for the language. We show how, based on a constraint-based capture of well-formedness, projectional editors canbe empowered to enforce well-formedness in much the sameway they enforce conformance with the metamodel. �eresulting robust edits may be more complex than ordinary,well-formedness breaking edits, and hence may require moreuser involvement; yet, maintaining well-formedness at alltimes ensures that necessary corrections of a program arelinked to the edit that necessitated them, and that the pro-jectional editor’s services are never compromised by incon-sistent programs. Robust projectional editing is not a strait-jacket, however: If a programmer prefers to work withoutit, its constraint-based capture of well-formedness will stillcatch all introduced errors — unlike many other editor ser-vices, well-formedness checking and robust editing are basedon the same implementation, and are hence guaranteed tobehave consistently.

CCS Concepts •So�ware and its engineering → So�-ware maintenance tools; Semantics; Syntax; •�eoryof computation→Constraint and logic programming;

Keywords projectional editing, constraint propagation, ed-itors, well-formedness, static semantics

1 Introduction“robust, adj. 1. strong and healthy”[Webster’s Encyclopedic Unabridged Dictio-nary of the English Language]

Projectional editing means editing the internal representationof a program via projection to one or more surface notations

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copiesare not made or distributed for pro�t or commercial advantage and thatcopies bear this notice and the full citation on the �rst page. Copyrightsfor components of this work owned by others than the author(s) mustbe honored. Abstracting with credit is permi�ed. To copy otherwise, orrepublish, to post on servers or to redistribute to lists, requires prior speci�cpermission and/or a fee. Request permissions from permissions@acm.org.SLE’17, Vancouver, BC, Canada© 2017 Copyright held by the owner/author(s). Publication rights licensedto ACM. 978-1-4503-5525-4/17/10. . .$15.00DOI: 10.1145/3136014.3136034

(which may, but need not be, textual) [36]. For textual lan-guages, it does not rely on a standard text processor, butrather on a structure editor based on templates which arede�ned as part of the language speci�cation, and which theuser needs to �ll in. While still somewhat controversialamong programmers (see Section 8 for a discussion), projec-tional editors excel at supporting them with entering validprograms, by exploiting available structural and contextualinformation in the editing process [1, 14, 38].

However, even with projectional editors, it is easy to entermalformed, or to break well-formed, programs. For instance,changing the declared type of an entity may invalidate usesof this entity. Malformedness is a problem for editor servicesthat depend on program analyses that in turn depend onwell-formedness of programs (see [14] for a recent account),such as code completion and refactoring tools (which mayproduce incomplete or incorrect results if applied to mal-formed programs). On a larger scale, malformedness is alsoa problem for collaboration, namely if commits are not al-lowed to break programs, and are required to be frequent andsmall (to increase parallelism and to avoid merge con�icts).

Robust editing as de�ned in this paper means editing thatleaves a well-formed program well-formed (and that is hencehealthy and strong). As we will see, robust editing mayrequire individual, intended edits to be complemented byadditional, complementing edits that maintain (or restore)well-formedness; yet, robust edits are atomic in the sensethat they are either performed completely or not at all.

We present an implementation of robust editing as a newlanguage service of the projectional editing environmentMPS1. Our robust projectional editor (RPE) builds on twoDSLs: one for specifying well-formedness, and one for spec-ifying robust editing pa�erns (named edit intentions). �eformer replaces MPS’s currently di�erent DSLs for type andother checking rules, as well as its (again di�erent) DSL forscope constraints, not only providing for a single point ofreference for a language’s static semantics, but also allowingall rules to be exploited in concert for computing robust edits.�e la�er provides for the speci�cation of a catalog of namedediting pa�erns that are seamlessly integrated with existinglanguage services of MPS.

While our implementation of robust editing draws oninsights gained from our works on constraint-based refactor-ing and repair [22, 26–29], it di�ers substantially not only inits purpose, but also by replacing standard constraint solvingwith custom implementations of constraint propagation. �e

1h�ps://www.jetbrains.com/mps/

SLE’17, October 23–24, 2017, Vancouver, BC, Canada Friedrich Steimann, Marcus Frenkel, and Markus Volter

la�er allows us to introduce special purpose constraints and,more importantly, to interleave the search for a solution withuser interaction, thus avoiding the computation of solutionsthat the user will dismiss. Our work not only �lls a hole inthe array of language services that can be generated from asingle constraint-based speci�cation of a language’s static se-mantics [25], it also responds to a recent call for researchingthe semantic foundations of editors [14].

Our paper is organized as follows: A�er a motivatingexample (Sect. 2), we lay the foundations of robust projec-tional editing (Sect. 3) and state the problem we are address-ing (Sect. 4). We present a generic solution of the problem(Sect. 5) and complement it with edit intentions (Sect. 6).A�er a detailed account of our implementation (Sect. 7), wediscuss our work (Sect. 8) and relate it to others (Sect. 9).

2 Motivating ExampleTo motivate our notion of robust edits, we assume here asimple language with modules and records (LMR; see [33]for its de�nition, and Figure 1 for an excerpt of its abstractsyntax), in which we have wri�en the (incomplete) program

prog

module A record Y { c : X } end

module B record Y { a : X } end

import A

record X { a : X b : X }

def x : X = new X {}

def y : Y = new Y {}

def z = x._

end

At the position of the underscore (the current editing posi-tion), the RPE that we envision would o�er us a choice of {a,b} for selection. �e RPE can infer this choice from (i) struc-tural knowledge, knowing that, in LMR, only a reference to arecord �eld can occur on the right of the dot, restricting thechoice to {a, b, c, B.Y.a}; and from (ii) program-level typeinformation, knowing that the type on the le� of the dot, thetype of x, is X, which has members a and b, thus restrictingthe choice to {a, b}. Note that, were the �eld access a en-tered before the receiver x, the choice for the �eld would be{a, b, c} (using scope information to exclude B.Y.a); a�erselecting a, well-typedness would require the receiver (le�of the dot) to have type X, including x, but ruling out y forselection.

Suppose that we have entered x.a, but now want to re-place x with y. As noted above, this would render the pro-gram ill-typed. However, rather than preventing this editingintent, a more useful RPE would allow the user to choose yanyhow, requiring selection among a number of options thatmaintain the program’s well-formedness. Option 1© wouldbe to also replace a by c; option 2©would be to move the �elddeclaration a from type X to type Y, option 3© would be tochange the type of y and its initializing expression to X; and

option 4© to import module B instead of A, replace the typeA.Y of y with B.Y, and select B.Y.a instead of X.a2. Last butnot least, as option 5© the �eld access can be removed. Notethat each option results in a well-formed program, in which(with the exception of the last) x in x.a has been replaced byy, the original editing intent; the last one is somewhat specialin that it deletes a program element (rather than changingan existing one).

If deleting is an edit option, then adding should also be.Indeed, there is yet another option 6© that users of a standardeditor can readily choose, by going through a temporarilymalformed program: replace x with y and add and select anew �eld a to A.Y. In fact, adding new program elementsonly a�er using them in a program under edit is a commonprogramming practice, one that contemporary projectionaleditors do not support, because every reference eagerly bindsto its target when it is entered. To automatically complementa reference to a new program element with creating theelement, an RPE would need to infer, from the current editposition, where the new program element (here: a new �elda) is to be added (here: to A.Y).

3 FoundationsWe de�ne here the context in which we assume our RPE tooperate: the abstract syntax, or language model, of the objectlanguage (i.e., the so�ware language the RPE is provided for),and the object language’s rules of well-formedness (staticsemantics; but recall that for projectional editing, this usuallyexcludes rules of name binding; cf. Footnote 2).

3.1 Language ModelFollowing Lammel [7], we assume that a program is repre-sented by an a�ributed abstract syntax graph (ASG), whereeach node is an instance of a struct3. �e edges of the ASGare encoded using reference a�ributes of the nodes, whichare complemented by a�ributes holding values.4 It followsimmediately that the primitive edit operations we need toconsider are• adding and deleting nodes of an ASG, and• assigning values or references to a�ributes.

Note that any ASG can be built (from scratch) using theseoperations, and can be changed in every conceivable way.�us, the primitive edit operations su�ce to describe allchanges a programmer may wish to make to a program5.

Further following Lammel [7], we assume a conformancerelation of ASGs to structural constraints expressed by a2Projection implies that references are not re-computed by resolving names— they must be updated manually. See Section 8 for a discussion.3We us the term struct rather than type here in order to avoid confusionwith the types de�ned and used by programs. Classi�er, class, sort, syntacticcategory, or concept are also in use; we prefer struct, because it suggests thenotion of well-structuredness which we will introduce below.4In OMG terms, our a�ributes would be called properties, which comprisevalue a�ributes (called a�ributes) and reference a�ributes, called links.5From here on, we use the terms ASG and program interchangeably.

Robust Projectional Editing SLE’17, October 23–24, 2017, Vancouver, BC, Canada

metamodel of the object language, such as that provided inFigure 1 (for the language LMR [33], adopted here for itsfocus on scope). Speci�cally, for an ASG to conform to ametamodel we require that• each node of an ASG is an instance of a struct declared

by the metamodel,• the a�ributes a�ached to a node are precisely those

declared as members of its struct or inherited fromits superstruct (declared in Figure 1 using “<:”),• the values or references held by a�ributes are ele-

ments of the a�ributes’ declared value types or refer-ences to instances of the a�ributes’ declared structsor superstructs, resp., taking the a�ributes’ declaredmultiplicities into account, and• each reference held by an a�ribute references an ex-

isting node (i.e., there are no dangling references).Here, value (or data) types, which are not de�ned by themetamodel, are str, int, bool, etc.; multiplicities are eitherone (the default), or option (declared by appending “?” tothe a�ribute’s declaration; cf. Figure 1), or many (appending“*”). We call an ASG that conforms to a metamodel well-structured.

Once more following Lammel [7], we assume that an ASGis overlaid by a tree structure, which is established by abidirectional parent-child (or containment) relationship andwhich is implemented by using special reference a�ributes(declared with the keyword child in place of ref in themetamodel of Figure 1; the reverse direction is establishedby an implicit parent a�ribute). While such a tree structuremay not be needed, in practice, we �nd that most so�warelanguages suggest it, if only to de�ne a linear representationof the program, but usually also to express a whole-part rela-tionship (constituency) and hierarchically nested scopes. Ifit is used by a metamodel, well-structuredness encompassesthat the parent-child relation is a tree (or a forest).

While well-structuredness is usually considered a prereq-uisite for deciding well-formedness (see Section 3.2), primi-tive edit operations may lead to states in which the ASG isnot well-structured. Speci�cally, a�er adding a new node,mandatory a�ributes (with multiplicity one) may not havebeen assigned yet6, and a�er deleting a node, references maybe dangling. We call an ASG that is well-structured exceptfor possibly unassigned a�ributes or dangling references,pre-structured, and note that pre-structured ASGs can bemade well-structured by assigning values or references toa�ributes; i.e., by primitive edit operations.

Finally, we assume that a projectional editor always leavesa pre-structured ASG at least pre-structured, and further-more that the only way a projectional editor can make awell-structured ASG pre-structured is by adding or delet-ing nodes. It follows that if a program is entered entirely

6Note that this does not mean that the a�ributes are assigned null; rather,their dynamic multiplicity [24] is — illegally — zero.

struct Prog {child decls:Decl*}

abstract struct Decl {}

struct Module <: Decl {

val id:str;

child decls:Decl*

}

struct Import <: Decl {ref module:Module}

struct Def <: Decl {

val id:str;

ref type:Record;

child exp:Exp

}

struct Record <: Decl {

val id:str;

child fields:Fdecl*

}

struct Fdecl {val id:str; ref type:Record}

abstract struct Exp {ref type:Record}

struct New <: Exp {

ref record:Record;

child inits:Fbind*

}

struct DotExp <: Exp {

child left:Exp;

ref field:FDecl

}

struct VarRef <: Exp {ref var:Def}

struct FBind {

ref field:Fdecl;

child exp:Exp

}

Figure 1. Speci�cation of graph-based abstract syntax (meta-model) of LMR (simpli�ed excerpt).

using a projectional editor, it is pre-structured at all times.To ensure that no ill-structured ASGs result from assigningreference a�ributes, a projectional editor will o�er only theexisting nodes (instances) of the a�ribute’s declared structor substructs for selection (so that no dangling references orreferences to nodes of other structs can be assigned). Notethat some projectional editors (including MPS) may furtherrestrict the selection of references by taking scope rules intoaccount, but we will not treat scope rules di�erently fromother rules of well-formedness, and hence do not considerthis possibility at this point.

3.2 Well-formednessMost object language speci�cations impose constraints onASGs that go beyond well-structuredness. Notably, this in-cludes the rules of the used type system and the scope rulesof a language. Although these rules are traditionally handledseparately, we do not do so and instead express all rules

SLE’17, October 23–24, 2017, Vancouver, BC, Canada Friedrich Steimann, Marcus Frenkel, and Markus Volter

context Def inv "var type":

self.type = self.exp.type

context Def inv "unique var names"

group d1, d2 by parent:

d1.id , d2.id

context Def inv "type access ":

self.type.parent = self.parent.parent* or

self.type.parent in

self.parent.decls <Import >. module

context DotExp inv "field access ":

self.field.parent = self.left.type

context Fdecl inv "unique field names"

group f1, f2 by parent:

f1.id , f2.id

context VarRef inv "var ref type":

self.type = self.var.type

context DotExp inv "dot type":

self.type = self.field.type

Figure 2. Some invariants for LMR expressed in our con-straint DSL used by our RPE to check well-formedness andto infer types.

of well-formedness jointly, using the same constraint lan-guage.7 Note that to be able to evaluate well-formednessrules on an ASG, both the ASG and the rules must conformto the metamodel (because otherwise, a rule might a�emptto access an a�ribute that is not declared for a node, so thatevaluation gets stuck); while evaluation of well-formednessrules usually requires that ASGs are well-structured, wewill relax this condition in Section 5, requiring only theirpre-structuredness.

Figure 2 shows type, scope, and other well-formednessrules for LMR, wri�en in a constraint language designed forthis purpose. Following the example of the Object ConstraintLanguage (OCL) [13], each rule is a�ached to a struct of themetamodel, which provides the contexts of its evaluation.For instance, the rule “var type” is associated with the structDef (see Figure 1), and is applied to each of its instances(represented in its body by the special variable self). �egroup ... by clause used in “unique var names” introducestwo variables d1 and d2 bound to all instances of the contextDef so that d1 , d2 and both share the same parent.

As in OCL, reference a�ributes are implicitly dereferencedby the dot operator. For instance self.exp.type (from“var type”) refers to the type a�ribute associated with thenode referred to by self.exp. �is allows us to expressscope rules as path expressions. As a specialty, we introducethe star (“*”) for navigating an a�ribute transitively zero

7�at scope rules and type rules may be di�cult to separate can be seenby the static imports of Java, and also how in Java the availability of typemembers depends not only on the type of the receiver, but also (via accessmodi�ers) on the type’s and the receiver’s locations in the program.

to n times: for instance, parent* in self.type.parent =self.parent.parent* (from “type access”) means that thenode denoted by the le�-hand side must be reachable bytransitively navigating the parent a�ribute, starting fromself.parent. �is saves us from having to pass sets of de-clared entities “in scope” (symbol tables, or environments)around.

Also following OCL, path expressions can be many-valued.For instance, self.parent.decls<Import>.module (fromrule “type access”) denotes many references to modules, eventhough each a�ribute module holds only a single reference(the operator in tests membership as usual). Here, the ex-pression decls<Import> selects all import declarations fromthe declarations held by decls. Note that while these spe-cial constructs of our constraint DSL are straightforward toevaluate (as required for checking well-formedness), theyare a challenge for constraint propagation, as we require inthe implementation of our RPE.

It is important to note that while the rules of Figure 2de�ne well-formedness for a well-structured ASG, some ofthem can also be used to infer values or references for at-tributes. Notably, “var ref type” and “dot type” serve tocompute the type of expressions, and “var type” can be usedto infer the type of a variable not speci�ed in a def (e.g., zin our example). �is will be returned to in Section 5.

4 Problem StatementWhile we may assume that projectional editors always pro-duce ASGs that are at least pre-structured (see Section 3.1),we may not expect guarantees with respect to the well-formedness of the resulting ASG (as noted in Section 3.2,for an ASG that is not well-structured, well-formedness maynot even be de�ned). Hence, the problem of robust projec-tional editing is to complement the primitive edit operationso�ered by a projectional editor, which may make the ASGmalformed or its well-formedness unde�ned, with the prim-itive complementing edit operations that are required to ob-tain a well-formed ASG. �e problem of implementing anRPE is thus (1) to compute the complementing edit opera-tions required for each o�ered primitive editing operation,and (2) to replace the o�ered primitive editing operationswith (complemented) tuples of primitive edit operations —called robust edit operations — from which the user can select.�e execution of a selected robust edit operation must beindivisible: either all comprised primitive edits are executedtogether, or none at all.

Leaving questions of user interface (UI) aside, the compu-tation of the complementing edit operations is complicatedby a number of technical challenges:

• For the complementing edit operations there may bemany alternatives, none of which can be excluded apriori. Generally, computing complementing edits isa search problem, which may be di�cult to con�ne.

Robust Projectional Editing SLE’17, October 23–24, 2017, Vancouver, BC, Canada

• If reference a�ributes are dereferenced in the courseof checking well-formedness (cf. Section 3.2), com-plementing edits may a�ect dereferencing (by re-assigning reference a�ributes). �is complicates thesearch considerably.• �e search is further complicated by the *-operator

(introduced in Section 3.2), which may involve anarbitrary number of reference a�ributes, all of whichmay be re-assigned.

�e following two sections deal with the speci�cs of oursolution on a more abstract level; Section 7 presents detailsof the actual implementation.

5 Generic Solution�e guiding idea of our solution is to encode well-formednessas a constraint satisfaction problem (CSP) [31], and to computerobust edit operations using constraint solving techniques.As usual, a CSP is de�ned here as a set of constraint variables,each associated with a domain from which its possible valuesare drawn, and a set of constraints, or relations, on thesevariables. For the encoding, we map

1. the a�ributes of an ASG to constraint variables,2. the extensions of the structs and value types of an

ASG to domains of the variables, and3. the well-formedness rules to constraints on the vari-

ables.Note that the second leg of the mapping includes a mappingof the nodes of an ASG to values of domains of the CSP, and ofvalues and references held by the nodes’ a�ributes to valuesof the corresponding constraint variables. Also note that forthe mapping to be well-de�ned it su�ces that the ASG ispre-structured (see Section 3.1 for the de�nition); unassigneda�ributes or reference a�ributes holding dangling referencesare mapped to unassigned constraint variables.

To illustrate the mapping, we revisit the (incomplete) de�-nition def z = x. from our motivating example, which isrepresented by the ASG nodes

[id = ‘z’, type = , exp =↑1]0 : Def[left =↑2, field = , type = ]1 : DotExp

[var =↑3, type =↑4]2 : VarRef[id = ‘x’, type =↑4, ...]3 : Def

[id = ‘X’, ...]4 : Record

Here, an integer subscript i marks the target of all references↑i , a node that is an instance of the struct given a�er thecolon; the underscore marks an a�ribute whose value orreference has not yet been set. Each a�ribute a of eachnode i is then mapped to a constraint variable ↑i .a, whoseinitial value is the value or reference provided in the ASG.Invariants like those of Figure 2 are mapped to constraintsby applying them to the instances of their context structs; forinstance, applying the invariants “var type” and “dot type”

from Figure 2 to the above instances (nodes of the ASG)produces the constraints

↑0.type =↑0.exp.type↑3.type =↑3.exp.type↑1.type =↑1.field.type

Note that, once the field a�ribute of node 1 has been as-signed, the reference of the type a�ribute of node 0 canbe computed by constraint solving, and that the same con-straints can be used to check the well-typedness of a de�ni-tion in which the type of z is declared (rather than inferred,as in our example). �is supports our claim that we make dowith a single speci�cation of static semantics for all purposes.

A more formal account of how invariants of an OCL-likelanguage can be mapped to constraints amenable to con-straint solving can be found in our recent publication onpartially evaluating OCL expressions [32]; in this presentwork, we deviate from this approach in that we do not ac-tually generate the constraints (and do not use a constraintsolver for solving them), but rather propagate them on the�y (see Section 7).

Our mapping of an ASG and the well-formedness rules ofthe language to a CSP is meaning-preserving in the sensethat if and only if the ASG is well-formed, the CSP is satis�edwith variable assignments representing the ASG. �is meansin particular that the variable assignment representing awell-formed ASG before a robust edit, and the variable as-signment representing the ASG a�er it, satisfy the CSP. Also,every changed variable assignment of the CSP representsan edited ASG (and with it an edited program), namely onein which a�ributes (in case of reference a�ributes: edges!)have changed. Note that assigning values to unassignedconstraint variables corresponds to making a pre-structuredASG well-structured, meaning that we can use our mappingto make a pre-structured ASG (for which well-formednessis unde�ned; see Section 3) resulting from a primitive editwell-formed.

While the mapping of nodes and their a�ributes is straight-forward, the mapping of well-formedness rules is compli-cated by implicit and explicit quanti�cation over the exten-sion of structs which, since CSPs do not cater for quanti�-cation, must be unrolled. In particular, for well-formednessrules relying on the dereferencing of reference a�ributes, wecannot assume that the references do not change (referencea�ributes are also mapped to variables, which may be re-assigned by constraint solving), so that dereferencing mustbe encoded explicitly in the constraints the well-formednessrules are mapped to. For instance, the constraint variablerepresented by ↑1.field.type changes with the value of↑1.field, so that the mapping of well-formedness rules con-taining this expression to constraints must unroll over theextension of ↑1.field’s declared struct (Fdecl in our exam-ple). While there are various ways to accomplish this (seeSection 7 for our current solution, and Section 9 for other

SLE’17, October 23–24, 2017, Vancouver, BC, Canada Friedrich Steimann, Marcus Frenkel, and Markus Volter

approaches we are aware of), unrolling remains a problemwhen the extensions (domains) being unrolled over are them-selves variable, which is inherently the case when membersare added or removed as part of editing (see below).

5.1 Computing Robust EditsGiven the above mapping from ASGs to CSPs, the primitiveedit operations of Section 3.1 (recall that these are all weneed to consider) correspond to changes of CSPs as follows:• Assigning a value or a reference to an a�ribute cor-

responds to assigning the mapped value or referenceto the mapped constraint variable.• Adding a node to an ASG corresponds to adding (a)

the mapped value to those domains of constraint vari-ables that are mapped from the struct the node is aninstance of, (b) the constraint variables correspondingto the a�ributes of the node, and (c) the constraintsthat constrain these variables.• Deleting a node corresponds to deleting (a) the mapped

value from the domains determined as above, (b) theconstraint variables, and (c) the constraints.

Note that for adding, the CSP must fully cover the new node,as demanded by items (a) through (c) above. (c) is compli-cated by the fact that the added node has not been consideredin the unrolling of any of the quanti�cations mandated bymapping the rules of well-formedness for the original CSP,including those resulting from path expressions (see above).�ere are two ways to ensure this: (1) re-map the ASG to aCSP a�er the node has been added, and (2) assume a reservoirof unused nodes that become used by referencing them. �eformer will preclude constraint solving from computing addoperations as complements of a given refactoring intent, andhence limit the power of an RPE; the la�er requires that theunused nodes are “parked” so that they do not appear in pro-jections of the ASG. For deleting, the situation is analogous:the ASG is either remapped, or the deleted nodes are parked,making sure that they are no longer referenced. Note thatthe la�er enables a wide range of complementing edits: forinstance, when deleting a parent node, its children (who losttheir parent) can either be deleted (not referenced) as well,or be assigned another parent (including the parent of theiroriginal parent, if this is covered by the declared parent-childrelationship; we will present an example in Section 6).

To summarize, we have that by expressing an editingintent, a user identi�es one or more a�ributes that are tobe assigned. To make sure that the pending assignmentsmake the ASG well-structured and well-formed, we map theASG to a CSP and subject this CSP to constraint solving.Each solution of the CSP is comprised of speci�c variablesassignments and hence presents an alternative robust editoperation, from which the user can select to ful�ll the editingintent.

Simple as this approach may seem, it has to master twonontrivial practical problems:

1. �e CSP encoding an ASG and its well-formedness istoo big to handle in the general case.

2. �e CSP may have too many solutions to choose from.�e problems are related in that if we �nd ways to managethat the CSPs become smaller, we will also receive fewer so-lutions. However, since “fewer solutions” does not automati-cally converge to “the solutions that the user appreciates”,we must involve the user in exploring the solution space.

5.2 Exploring the Solution SpaceAs suggested above, exploring the solution space is com-prised of controlling its size and selecting a solution.

5.2.1 Controlling the Solution SpaceWithout further input from the user, the variables selectedby the editing intent are the only ones we allow the con-straint solver to re-assign, with three possible outcomes: thecorresponding CSP is unsatis�able, its solutions appear un-satisfactory to the user, or the user selects one for execution.For instance, in the context of our motivating example ofSection 2, our RPE o�ers a choice of a and b

selecting from which assigns the corresponding reference tothe constraint variable representing the reference a�ributefield of the instance of struct DotExp representing the (in-complete) dot expression, satisfying the constraint “�eldaccess” (the only constraint of Figure 2 involving field vari-ables).8 If this choice appears unsatisfactory to the user, moresolutions (which would also be required by an unsatis�ableCSP) are obtained by either adding program elements, or bymaking more a�ributes re-assignable; speci�cally by makingthose a�ributes assignable that constrain the currently as-signable a�ributes directly (in the above example, by addinga new �eld to record X, by making type of the receiver heldby left assignable, or by making left itself assignable).�is process can be repeated until a (satisfactory) solutionis found. Ultimately, however, it will lead to a new problem:the problem of an exploded solution space, which the userhas to conquer.

5.2.2 Selecting a Robust EditSelecting from a large solution space may be challenging(if only for the many repeating groups that alternative so-lutions will contain) and in any case is rather remote fromprojectional editing as we know it. We therefore project theset of alternative robust edits to the a�ributes involved, sothat for each a�ribute, the user gets a choice of values orreferences. �e choices are dependent in that every selection8Incidentally, these are the same choices that would be o�ered by a standardimplementation of LMR in MPS, but only if the type rules are implementedas scope rules; see Section 9.

Robust Projectional Editing SLE’17, October 23–24, 2017, Vancouver, BC, Canada

(a) Looking at the solution space. (b) Selecting �eld c.

(c) Con�rming variable x. (d) Con�rming that c has movedfrom Y to X.

Figure 3. Robust edition session (all screenshots taken fromour implementation described in Section 7).

of a value or reference for one of these a�ributes restrictsthe available choices for the remaining a�ributes, until nomore choices remain, which is when a robust edit has beenselected. �e individual choices, of which there will be atmost as many as a�ributes are involved, must be enclosed intransaction braces (begin edit and end edit) so as to guaranteethat well-formedness is accomplished (or the editing intentgiven up) before the next robust edit commences.

To see this working, we have adopted our Solution SpaceExplorer [26] as a prototype UI for robust projectional edit-ing. Continuing the motivating example where we le� in

Section 5.2.1, and assuming that the user found her selectionof a unsatisfactory (and therefore asked for more alterna-tives), our RPE responds with the dialog shown in Figure 3a.It shows all a�ributes that immediately (i.e., through nomore than one constraint) constrain the unsatisfying choice,and o�ers alternative assignments for some (column “new”).�at the current assignment (“old”) makes the program well-formed is indicated by the fact that the “OK” bu�on is active.

From the o�ered alternatives, the user can make selectionsin arbitrary order. For instance, if c is the �eld that is to beaccessed on x, this can be selected �rst (Figure 3b). Note howthis makes the program malformed, indicated by the disabled“OK” (Figure 3c). If x is nevertheless the variable on whichc is to be accessed, this can be con�rmed, by selecting x asin Figure 3c. �is selection uniquely determines the parentof �eld c (was: Y), as can be seen from Figure 3d, in whichX now appears as unchangeable in column “new”. Pressingthe (now available) “OK” executes the selected robust edit.

�e solution space explorer is also used as a prototype UIfor adding and deleting nodes, when a�ributes need to be(re-)assigned as a result (see Section 5.1). For a discussion ofthis UI, we refer the reader to Section 8.

6 Edit Intentions�e main problem of the generic solution presented aboveis that the user may quickly get lost in the solution space(but see Section 8 for an outline of a be�er UI). Given that inmany cases, the editing problems and their solutions will bestereotypical in nature, exposing the user to the full spaceseems unnecessary. For instance, looking at the edit optionsof our motivating example from Section 2, we can identifyat least the following pa�erns of robust edit operations:

• Select a valid pair of a record-typed variable and a�eld accessed on it (option 1© in Section 2).• Select a variable and a new �eld added to the record

that serves as the type of the selected variable, se�ingthe type of the �eld to �t the context (option 6©).• Select a variable and delete the �eld access ( 5©).

Since they express what the user has in mind with an in-tended edit, we call pa�erns of this kind edit intentions, orintentions for short.

Figure 4 shows intention speci�cations capturing the aboveinformally speci�ed pa�erns in a DSL designed for this pur-pose. All three speci�cations are associated with the structVarRef, of which the use of x in x.a is an instance; selfrefers to the instance of the struct the intention is appliedto. Note that our intention DSL borrows the path expres-sions from our constraint DSL of Section 3.2, for identifyinga�ributes that may (or must) be re-assigned.

�e �rst speci�cation, named “select 〈variable.�eld〉”, isa modify intention stating that the node’s a�ribute var (cf.Figure 1) and its parent’s a�ribute field can be assignednew references. Here, parent<DotExp> expresses that the

SLE’17, October 23–24, 2017, Vancouver, BC, Canada Friedrich Steimann, Marcus Frenkel, and Markus Volter

modify "select <variable.field >" {

self.var

self.parent <DotExp >.field

}

add "select <variable.newfield >" {

struct: Fdecl

assign: self.parent <DotExp >.field

modify: self.var

}

replace "select <variable > & delete ." {

become:

self.parent <DotExp >

self

modify: self.var

}

Figure 4. Intention speci�cations associated with VarRef.

parent of self must be an instance of DotExp; otherwise,the intention cannot be applied.

�e second speci�cation “select 〈variable.new�eld〉” is anadd intention that creates a new instance of struct Fdecl andassigns a reference to this instance to the field a�ribute ofthe parent of the node on which this intention is invoked. �emandatory a�ributes of the new �eld (speci�cally: id, type,and parent, i.e., the record to which the �eld is added), areautomatically selected as assignable (they must be assignedfor the program to be well-structured; cf. Section 3.1). �emodify clause of this intention expresses that additionally,the var a�ribute may be re-assigned (in our example froma reference to x to one to y). Note that, in our example, theparent of the new �eld is uniquely determined by the well-formedness constraint “�eld access” and follows the type ofthe variable, meaning that if the user selects a reference to yfor self.var, the new �eld declaration is added to recordY. Also note that, if the user names the new �eld “a”, thename disequality constraint “unique �eld names” of Figure 2prevents that it is added to X; x can therefore not be selected,unless more solutions are requested (see below). �e type ofthe new �eld is constrained by the type of the dot expression(“dot type”), which is constrained (via “var type”) to the typeof z; however, since these are not declared as re-assignable,the type for the new �eld is set to X, the type of old �eld a.Note that type a�ributes can be declared as assignable, too,but type changes can propagate widely through a program,bordering on type refactorings [30] (see below and Section 9).

�e third speci�cation “select 〈variable〉 & delete .” isa delete intention that re-assigns all a�ributes referencingthe �rst argument of become: (reminiscent of Smalltalk’sbecome:) with a reference to the second (in our example,references to the expression x.a are replaced with referencesto x). A dynamic check associated with become: allowsthis intention to be applied only if it leaves the ASG well-structured, speci�cally, if the declared struct of each a�ribute

holding a reference to the dot-expression is a superstruct ofDotExp and VarRef.

Each of these intentions speci�es generically which at-tributes (constraint variables) may or must be re-assignedto perform the associated edit operations; it is understoodthat all others remain untouched (“frame axiom”). If thecorresponding CSP has no solutions, the user can requestan expansion of the editable a�ributes, by branching to thesolution space explorer; in fact, for the selection of the as-signments necessary to specify the concrete robust edit (theinstantiation of the pa�ern speci�ed by an intention), wecurrently branch to the solution space explorer anyway, re-stricting the available selections to those speci�ed by theintention. For instance, applying the edit intention “select〈variable.�eld〉”, the user sees

o�ering the currently available robust edits instantiating thepa�ern, and the possibility to request more.

Our edit intentions are somewhat similar to quick-�xes,and also to refactoring tools, in that they encode stereotypi-cal edit operations; however, unlike the la�er two, they donot require separate implementations, but are completelydriven by existing well-formedness rules (see Section 9 for acomparison with related work). In fact, since our intentionsare completely speci�ed using a (fairly simple) DSL, versedusers can easily extend the intention catalog shipped withthe RPE with their favorite edit intentions.

7 ImplementationSo far, we supposed that an ASG and editing intent aremapped to a CSP, which is then submi�ed to a constraintsolver. However, a number of reasons let this procedureappear less than ideal.• Constraint solving can quickly become very expen-

sive. �is is especially so for mostly symbolic domains(which ASGs are) abounding with disjunctions, as in-troduced by path expressions (see Sections 5 and 9),which force the solver to branch. Especially for largeASGs, with nodes in the millions, the unrolling ofpath expressions is very hard to con�ne so that theresulting CSPs can be solved in acceptable time.• To present the user with all available options to com-

plete an editing intent, we need to compute all so-lutions of a CSP. �is voids all a�empts of solversto �nd the �rst solution quickly — it is the e�ort re-quired to compute the last that limits the utility ofconstraint solving for our purpose.

Robust Projectional Editing SLE’17, October 23–24, 2017, Vancouver, BC, Canada

• While all solutions are required, the selection processdescribed in Section 5.2.2 projects these solutions todomains of variables, from which the user sequen-tially selects. �is means that, for any single selection,we do not need the complete set of solutions; a con-servative approximation ensuring that all availableoptions for a single a�ribute are actually supportedby a solution will be enough. Once a selection hasbeen made for one a�ribute, the approximation canbe updated for the remaining a�ributes, until onlyone a�ribute remains.

�e last �nding coincides with the fact that standard con-straint solving is divided into two phases: constraint prop-agation and search [31]. Constraint propagation usuallyestablishes a form of local consistency, essentially by remov-ing values from variable domains that are not supported byany assignment of other variables of the same constraint(see below), while search tries to �nd a solution in the space(Cartesian product) set up by the so-reduced domains. Notethat, while search is generally su�cient to solve a CSP, thereduction of the search space bought by constraint propa-gation usually expedites search tremendously, and hencecontributes much more to constraint solving than it costs.�e domains obtained by constraint propagation are closeto the conservative approximation that we required abovefor selecting a value of any single a�ribute; to be su�cient,however, they would also need to be globally consistent [3].

To compute consistent domains, we build on Mackworth’soriginaln-ary arc consistency algorithm NC [9]. In a nutshell,NC maintains a queue (worklist)W of pairs (C,x), initializedwith all constraints C and constraint variables x of a CSPsuch that x is directly constrained by C . FromW , and untilW is empty, NC removes a pair (C,x) and from the domainof x , Dx , all values that are not supported by values fromthe domains Dx ′ of C’s other directly constrained variablesx ′.9 If this leaves Dx empty, the algorithm terminates withthe result that the CSP is inconsistent (no robust edit canbe computed for the ASG, intent, and assignable variables).Else, if any values were deleted from Dx , it appends all pairs(C ′,x ′) such that C ′ , C and C ′ directly constrains x , andx ′ , x and x ′ is directly constrained by C ′.

When W is �nally empty and more than one variabledomain has more than one value (“non-singleton domain”),NC continues by bisecting one of these domains, and startingover for each of the resulting CSPs. Upon termination of thisrecursive procedure, each terminal process provides n sets ofsolutions, where each set is comprised of one of the n valuesof the remaining non-singleton domain (if present), and thevalues from the singleton domains.

9A value of a variable of a constraint is supported if the constraint can besatis�ed by assigning its other directly constrained variables values fromtheir domains.

Straightforward though it may seem, application of NC inour domain is threatened by the high arity of constraints in-volving path expressions. Indeed, as noted in Section 5, in aconstraintC mapped from a well-formedness rule involving apath expression like self.field.type, if the variable repre-senting self.field can take on any of n values, each valueleads to a di�erent type constraint variable, increasing thearity of C by n. �is would not only make checking the sup-port for values of variables fromC more expensive, but wouldalso increase the length of the worklist considerably. How-ever, due to the disjunctive nature of path expressions (onlyone of the n variables is selected, and hence constrained, byany concrete path), all values for variables reached in a con-straint exclusively via the dereferencing of others are alwayssupported, as long as it may be the case that the variablesare not selected (in which case they are free to adopt anyvalue). For instance, if the domain of (the constraint variablerepresenting) self.field is {a, b}, any value in the domainof both a.type and b.type is supported, for a.type by as-suming the value b for self.x, and for b.type by assuminga. �e reader versed in constraint solving will recognize thisas a form of constructive disjunction [6], for which e�cient�ltering algorithms exist (ours builds on insights detailed in[8]). Note that, should the constraint propagation performedby NC reduce the domain of a dereferenced variable to a sin-gleton, the referenced variable becomes uniquely selected,and hence will become subject to domain reduction.

�e same reasoning applies to our *”-operator (see Sec-tion 3.2): While it introduces an arbitrary length path ex-pression, and with it may select a large number of additionalvariables, the domains of these variables cannot be reduced(for the same reasons as above), so that they need not beadded to the worklist. However, the variables may still needto be visited for �nding a support of other variables’ values;in these cases, the disjunctive nature of path expressionsallows the search to be aborted once one disjunct has led toa supporting value, so that the transitive closure implied bythe “*”-operator does not have to be explored in full.

A�er achieving local consistency, NC would continue bybisecting a non-singleton domain and recursing. However,given that we need the user to select a solution (Section 5.2.2),this appears premature — instead, we let the user select avalue from a non-singleton domain, and recurse with thedomain set to this value. To be sure that any selection froma domain computed by NC will actually lead to a solution,this procedure needs global consistency [3].

However, when achieving global consistency, we pay theprice for dropping from local consistency the variables ofpath expressions reached via dereferencing other variables.In untoward constellations (when their domains have notbeen restricted by other constraints), this may bring outthe exponential nature of global consistency, and stretchthe user’s patience accordingly. In these cases, we can stillpush global consistency to a background task, running for

SLE’17, October 23–24, 2017, Vancouver, BC, Canada Friedrich Steimann, Marcus Frenkel, and Markus Volter

completion while the user inspects the solution space assuggested in Section 5.2.2, only now with domains under-approximated by the achieved local consistency. �e user’sselections continuously reduce the size of the problem, mak-ing global consistency cheaper to achieve; in the worst case,the user has chosen a value that does not lead to a solutionof the CSP, in which case the process backtracks.

�e constraint solving required for the application of ro-bust editing intentions (as described in Section 6) is imple-mented in the exact same way; due to its inherent restrictionof the variables that are subject to constraint solving (i.e.,that may be assigned values), achieving global consistencyis not a problem here.

We have implemented our RPE on top of the meta-pro-gramming system MPS. Our implementation replaces MPS’suse of scope rules for determining possible selections of refer-ences with the more general constraint satisfaction approachdescribed in this paper, which allows other well-formednessrules (including type rules) to be exploited for the same pur-pose. In fact, this resolves one of the most criticized (amongmembers of our group) oddities of MPS, its reliance on threedi�erent mechanisms for enforcing scope rules, type rules,and other rules of well-formedness (each coming with itsown DSL), while at the same time allowing us to evaluatescope rules “reversely”, for computing legal locations fornewly added program elements. For reasons outlined above,we use a custom implementation for achieving local andglobal consistency; apart from liberating us from the lim-ited expressiveness of standard constraint solvers (e.g., noneknown to us supports transitivity as required by our “*” op-erator), it also allows us to propagate constraints “on the �y”,that is, without �rst se�ing up a complete constraint graph,and then transforming parts of it to a CSP submi�ed to aconstraint solver. �is greatly reduced the overhead of ourconstraint approach.

Standard MPS already comes with a notion of intentionsas atomic actions initiated by the user to modify an existingprogram in a prede�ned way. However, these intentions areprogrammed imperatively, and make no guarantees withrespect to well-formedness. Our intentions add to thoseo�ered by MPS, and are invoked in exactly the same way;in fact, entering the solution space explorer at any givenediting location is also implemented as an (MPS) intention.

8 DiscussionAlthough still not widely used by programmers, projectionaleditors are helpful for non-programmers writing programsin DSLs [37]. In fact, their support for �exible and mixedsyntax facilitates replicating a domain’s inherent notations,and their support for language modularity helps with thee�cient development of DSLs [35]. For programmers usingGPLs, these advantages may be outweighed by a clumsierediting process (cf. Footnote 2); yet, projectional editorsare increasingly being recognized as ideal launch pads for

advanced language services (see [14] and also Section 9), andindeed, building tool support for robust editing without theaid of projectional (or structure) editors seems hard [14].

We make no claims regarding the practicality of the proto-type UI of our implementation of an RPE, which we presentedin Sections 5 and 6. Speci�cally, we understand that it will behard for the user to relate nodes and properties shown in thesolution space explorer to the di�erent places in a programwhere they occur, but it is easy to conceive of an alterna-tive UI that comes with a robust editing mode, in which theprogram remains browsable/navigable as usual, but in-placeediting is limited to the alternative editing options currentlycollated in the solution space explorer, until a robust edithas uniquely been identi�ed and the robust editing modeis le� again. �e primitive edits yet to be decided on canbe maintained in a list for quick reference and navigation(not unlike the problems view we see in traditional IDEs),and exploring the solution space can be enhanced with undofunctionality; yet, given that undo does not work reliablyeven for standard MPS, this still seems some way to go.

Robust edits can be very powerful. For instance, by mov-ing def z = x.a (from the motivating example) to module A(expressed as a primitive edit by assigning the correspondingnode’s parent a�ribute a reference to the node of moduleA), the computed complementing edits will suggest to movethe nodes on which the moved nodes depends via scopeconstraints as well. While many would equate this changewith a refactoring (especially if o�ered as an intention “move〈node〉”), we uphold here the original de�nition of refactor-ing, which would require guarantees of the change beingbehavior-preserving (and not only well-formedness preserv-ing; see Section 9). In fact, programming may be seen asan alternating sequence of behavior-altering and behavior-preserving changes, and hence (since behavior preservationrequires and produces well-formedness), as an alternatingsequence of robust edits and refactorings: With our intro-duction of RPEs, we have complemented refactoring tools asautomated editing engines with an engine for performing thewell-formedness preserving changes between refactorings;together, they cover the full editing process.

While we presented robust projectional editing as a trans-formation from well-formed programs to well-formed pro-grams, the exploration of the solution space that we de-scribed and implemented suggests that only a small part ofthe program is mapped to a CSP, meaning that only for thispart, preservation of well-formedness is guaranteed. Whilethis does not invalidate our claims (robust editing will stillnot introduce malformedness), the requirement that the pro-gram must be globally well-formed before a robust edit isunnecessarily strong if one accepts that the well-formednesspreservation guarantee of robust projectional editing extendsonly to the parts covered by the editing. Note in particularthat this allows the program to be merely pre-structuredbefore a robust edit is performed, meaning that robust edits

Robust Projectional Editing SLE’17, October 23–24, 2017, Vancouver, BC, Canada

may be alternated with ordinary ones — the same constraintsthat would be used for computing robust edits are then usedto check well-formedness a�er the edit. However, as soonas the solution space associated with a robust edit extendsto a�ributes contributing to mere pre-structuredness or mal-formedness, the robust edit will ensure that these conditionsare resolved. Robust editing may thus also be used to repairmalformed programs.

9 Related WorkOur design and implementation of an RPE seems related tothe semantic foundations of program editors recently pos-tulated by Omar et al. [14]. Speci�cally, our pre-structuredASGs capture programs with syntactic holes, and represent-ing these holes as variables of a CSP allows us to reason about,and complete, incomplete programs. Furthermore, as hasbeen argued elsewhere [25], the same constraint-based cap-tures of well-formedness can also be used for repairing mal-formed programs [26] and, by additionally casting behavior-critical relations between program elements (nodes) to con-straints, for refactoring programs [22]. By contrast, editorservices o�ered by contemporary IDEs each rely on theirown implementation, and hence on a duplication of logic,causing the obvious consistency and maintenance problems.

�e propagation of change in presence of (OCL) con-straints has been a continuing theme in the works of Egyedand Reder (see. e.g., [4, 18, 19]). However, their implemen-tations appear to be based on explicitly maintained depen-dency graphs (along which concrete changes are propagated),and not on constraint solving techniques, as our work. Itis unclear how this addresses circular dependencies; also,without constraint propagation (arc consistency), it will bevery expensive to compute a complete set of legal (robust)edit alternatives for selection, as we do.

Robust editing is somewhat related to ad-hoc refactoring,or “refactorings without names” [22, 29], and intentions areloosely related to the refactoring speci�cation of Refacola[27]. �e main technical di�erences are that here, we do notdistinguish between a constraint generation and a constraintsolving phase and do not employ a standard constraint solverfor the la�er as we did in our previous works, but ratherapply local and global consistency techniques directly onthe internal representation of a program, and involve theprogrammer in the search that is normally performed bythe constraint solver. �is allows us to use the same set ofconstraints and technical infrastructure for checking well-formedness and for computing robust edits, avoiding theredundancy of (constraint-based) refactoring tool and (stan-dard) compiler from which all our constraint-based refac-toring tools su�ered. Robust editing is also related to codecompletion, as described, for instance, in [17].

MPS, on which we have implemented RPE, has nativemechanisms for enforcing scope rules, type rules, and otherconditions of well-formedness [34]. Scope rules, which are

called scope constraints in MPS, compute the set of avail-able targets for a given reference (that is, those programelements that are “in scope”), allowing the editor to enforce“well-scopedness” in addition to pre-structuredness as de-scribed in Section 3.1. When the user a�empts to establisha reference, only the targets in this set can be chosen from.�e same computation is used to check well-scopedness of aprogram a�er other changes: for this, the sets of available ref-erences are re-computed, and existing references that are notmembers of the “available” sets are �agged as a scope errors.By contrast, type rules do not constrain the construction ofthe program10; instead, they are evaluated as part of staticchecking, �agging errors “a�er the fact”. �e same holds forother conditions of well-formedness. By contrast, our im-plementation of RPE uses the same mechanisms uniformlyfor reference selection and checking; in fact, if the only editsallowed are robust edits, well-formedness checking will onlybe needed for loading programs that have not been wri�enusing our RPE. Because of this uniform treatment, we alsohave a single DSL for expressing scope rules, type rules, andother conditions, unlike MPS, which o�ers di�erent DSLsfor each purpose. Importantly, our approach also supportsthe on-demand creation of not yet existing reference targetsbased on the existing constraint-based description of scopingrules. MPS’s native approach does not support this; instead,on-demand target creators have to be implemented manually,duplicating the logic in the scoping rules.

�e integration of scope rules and type rules underlyingour RPE has also been suggested in [11, 33], in the contextof name binding. As far as type members are concerned,name binding is also touched on by the type constraints of[15, 30]; indeed, as we have shown elsewhere [23, 25], theconstraint-based coverage of type rules can be generalizedto cover name binding. However, name binding is not anissue in the context of projectional editing (see Section 3), sothat we do not use this feature here.

�e translation of path expressions (e.g., ↑1.field.type;see Section 5) is a common problem of mapping “object”constraint languages (i.e., constraint languages that assumeobjects and reference semantics of a�ributes;,e.g., OCL) toplain value-based constraint solvers, namely when a�ributeson the path can be changed by constraint solving (so that sub-sequent a�ributes are accessed indirectly). One solution is touse element constraints [5, 27], which model the indirectionwith an array access. Alternatively, if the used constraintsolver supports this, reference a�ributes can be mappedto uninterpreted functions (so that x.field.type becomestype(field(x))), le�ing the solver �nd values for functionapplications [2]. A solution that will work for any constraintsolver, yet may require clumsy constraint rewriting, is towrap indirect a�ribute access in conditional constraints, assuggested by [16, 23]. In any case, indirection has a heavy

10but note that access of type members is subsumed by the scope rules

SLE’17, October 23–24, 2017, Vancouver, BC, Canada Friedrich Steimann, Marcus Frenkel, and Markus Volter

performance penalty, particularly if the domain of the in-direction (i.e., dereferenced) variable cannot be su�cientlyrestricted. With our custom implementation of constraintsolving, we avoid this problem for ensuring local consis-tency (see Section 7); more generally, and since the problemcoincides with an exploded solution space, we counter itthrough the introduction of intentions (Section 6), whichlimit generic variability to the intended (“good”) parts.

10 ConclusionWhile the program analyses underlying editor services suchas code completion or refactoring tools require programsto be well-formed (or otherwise produce erroneous results),editing may leave a program malformed, even when projec-tional, or structure, editors are used. With our introductionof robust edits, we raise editing itself to a language servicethat complements intended edits with others that are re-quired to preserve well-formedness. We show how, froma user perspective, complexity is reduced by the introduc-tion of editing intentions, named pa�erns of stereotypicalediting operations declaratively speci�ed using a small DSL;technically, we tame it by involving the user in the com-putation of a robust edit, by interleaving local and globalconsistency techniques with the user’s selection of primitiveedit operations. Unlike that of most other language servicesin use today, our approach is fully declarative, using thesame speci�cation for checking well-formedness, type infer-ence, and computing robust edits, avoiding consistency andmaintenance problems by construction.

Acknowledgments�is work was supported by DFG grant STE 906/5-1.

References[1] �orsten Berger, Markus Volter, Hans Peter Jensen, Taweesap Dang-

prasert, and Janet Siegmund. 2016. E�ciency of projectional editing:A controlled experiment. In Proc. of the 2016 24th ACM InternationalSymposium on Foundations of So�ware Engineering. ACM, 763–774.

[2] Leonardo Mendonca de Moura and Nikolaj Bjørner. 2008. Z3: AnE�cient SMT Solver. In Tools and Algorithms for the Constructionand Analysis of Systems, 14th International Conference, TACAS 2008.Proceedings. 337–340.

[3] Rina Dechter. 1992. From Local to Global Consistency. Artif. Intell. 55,1 (May 1992), 87–107.

[4] Alexander Egyed. 2006. Instant consistency checking for the UML.In 28th International Conference on So�ware Engineering (ICSE 2006).381–390.

[5] Pascal Van Hentenryck. 1989. Constraint satisfaction in logic program-ming. MIT Press.

[6] Pascal Van Hentenryck, Vijay A. Saraswat, and Yves Deville. 1998.Design, Implementation, and Evaluation of the Constraint Languagecc(FD). J. Log. Program. 37, 1-3 (1998), 139–164.

[7] R. Lammel. 2017. So�ware languages: Syntax, semantics, and metapro-gramming. Springer. To appear. Book’s website: h�p://www.so�lang.org/book.

[8] Olivier Lhomme. 2003. An E�cient Filtering Algorithm for Disjunc-tion of Constraints. Springer, 904–908. h�p://dx. doi.org/10.1007/

978-3-540-45193-8 76[9] Alan K. Mackworth. 1977. On Reading Sketch Maps. In Proceedings of

the 5th International Joint Conference on Arti�cial Intelligence - Volume2 (IJCAI’77). Morgan Kaufmann Publishers Inc., 598–606.

[10] Raul Medina-Mora and Peter H. Feiler. 1981. An Incremental Program-ming Environment. IEEE Trans. So�ware Eng. 7, 5 (1981).

[11] Pierre Neron, Andrew P. Tolmach, Eelco Visser, and Guido Wachsmuth.2015. A �eory of Name Resolution. In Programming Languagesand Systems - 24th European Symposium on Programming, ESOP 2015.Proceedings. 205–231.

[12] David Notkin. 1985. �e GANDALF project. Journal of Systemsand So�ware 5, 2 (1985). DOI:h�p://dx.doi.org/10.1016/0164-1212(85)90011-1

[13] Object Management Group. 2014. Object Constraint Language Version2.4. Object Management Group.

[14] Cyrus Omar, Ian Voysey, Michael Hilton, Joshua Sunshine, Claire LeGoues, Jonathan Aldrich, and Ma�hew A. Hammer. 2017. TowardSemantic Foundations for Program Editors. In 2nd Summit on Advancesin Programming Languages, SNAPL 2017. 11:1–11:12.

[15] Jens Palsberg and Michael I. Schwartzbach. 1994. Object-oriented typesystems. Wiley.

[16] Nils Przigoda, Robert Wille, and Rolf Drechsler. 2016. Ground se�ingproperties for an e�cient translation of OCL in SMT-based model�nding. In Proc. MODELS 2016. ACM, 261–271.

[17] Veselin Raychev, Martin T. Vechev, and Eran Yahav. 2014. Code com-pletion with statistical language models. In ACM Conference on Pro-gramming Language Design and Implementation, PLDI ’14. 419–428.

[18] Alexander Reder and Alexander Egyed. 2012. Computing repair treesfor resolving inconsistencies in design models. In IEEE/ACM Intl. Conf.on Automated So�ware Engineering, ASE’12, 2012. 220–229.

[19] Alexander Reder and Alexander Egyed. 2012. Incremental ConsistencyChecking for Complex Design Rules and Larger Model Changes. InModel Driven Engineering Languages and Systems - 15th InternationalConference, MODELS 2012. Proceedings. 202–218.

[20] �omas W. Reps and Tim Teitelbaum. 1984. �e Synthesizer Generator.In First ACM SIGSOFT/SIGPLAN so�ware engineering symposium onPractical so�ware development environments. ACM. DOI:h�p://dx.doi.org/10.1145/800020.808247

[21] Charles Simonyi, Magnus Christerson, and Shane Cli�ord. 2006. In-tentional So�ware. In OOPSLA 2006. ACM.

[22] Friedrich Steimann. Constraint-Based Refactoring. ACM TOPLAS(��). to appear.

[23] Friedrich Steimann. 2015. From well-formedness to meaning preserva-tion: model refactoring for almost free. So�ware and System Modeling14, 1 (2015), 307–320.

[24] Friedrich Steimann. 2015. None, One, Many - What’s the Di�erence,Anyhow?. In 1st Summit on Advances in Programming Languages,SNAPL 2015. 294–308.

[25] Friedrich Steimann. 2015. Refactoring Tools and �eir Kin. In GrandTimely Topics in So�ware Engineering - International Summer SchoolGTTSE 2015, Tutorial Lectures (Lecture Notes in Computer Science),Jacome Cunha, Joao Paulo Fernandes, Ralf Lammel, Joao Saraiva,and Vadim Zaytsev (Eds.), Vol. 10223. Springer, 179–214. DOI:h�p://dx.doi.org/10.1007/978-3-319-60074-1

[26] Friedrich Steimann, Jorg Hagemann, and Bastian Ulke. 2016. Com-puting repair alternatives for malformed programs using constrainta�ribute grammars. In Proceedings of the 2016 ACM SIGPLAN Interna-tional Conference on Object-Oriented Programming, Systems, Languages,and Applications, OOPSLA 2016. 711–730.

[27] Friedrich Steimann, Christian Kollee, and Jens von Pilgrim. 2011. ARefactoring Constraint Language and Its Application to Ei�el. InECOOP 2011 - Object-Oriented Programming - 25th European Con-ference. Proceedings. 255–280.

[28] Friedrich Steimann and Bastian Ulke. 2013. Generic Model Assist. InModel-Driven Engineering Languages and Systems - 16th International

Robust Projectional Editing SLE’17, October 23–24, 2017, Vancouver, BC, Canada

Conference, MODELS 2013. Proceedings. 18–34.[29] Friedrich Steimann and Jens von Pilgrim. 2012. Refactorings without

names. In IEEE/ACM International Conference on Automated So�wareEngineering, ASE’12. 290–293.

[30] Frank Tip, Robert M. Fuhrer, Adam Kiezun, Michael D. Ernst, I�aiBalaban, and Bjorn De Su�er. 2011. Refactoring using type constraints.ACM Trans. Program. Lang. Syst. 33, 3 (2011), 9.

[31] Edward P. K. Tsang. 1993. Foundations of Constraint Satisfaction. Aca-demic Press.

[32] Bastian Ulke, Friedrich Steimann, and Ralf Lammel. Partial Evalua-tion of OCL Expressions. In Model-Driven Engineering Languages andSystems - 20th Intl. Conference, MODELS 2017. Proceedings. To appear.

[33] Hendrik van Antwerpen, Pierre Neron, Andrew P. Tolmach, EelcoVisser, and Guido Wachsmuth. 2016. A constraint language for staticsemantic analysis based on scope graphs. In Proceedings of the 2016ACM SIGPLAN Workshop on Partial Evaluation and Program Manipu-lation, PEPM 2016. 49–60.

[34] Markus Voelter, Sebastian Benz, Christian Dietrich, Birgit Engelmann,Mats Helander, Lennart CL Kats, Eelco Visser, and Guido Wachsmuth.2013. DSL engineering: Designing, implementing and using domain-speci�c languages. dslbook. org.

[35] Markus Voelter, Bernd Kolb, Tamas Szabo, Daniel Ratiu, and Arie vanDeursen. 2017. Lessons learned from developing mbeddr: a case studyin language engineering with MPS. So�ware & Systems Modeling(2017), 1–46.

[36] Markus Voelter and Sascha Lisson. 2014. Supporting Diverse Notationsin MPS’Projectional Editor.. In GEMOC@ MoDELS. 7–16.

[37] Markus Voelter, Jos Warmer, and Bernd Kolb. 2015. Projecting amodular future. IEEE So�ware 32, 5 (2015), 46–52.

[38] Markus Volter, Janet Siegmund, �orsten Berger, and Bernd Kolb. 2014.Towards user-friendly projectional editors. In International Conferenceon So�ware Language Engineering. Springer, 41–61.