Visitor-Oriented Programming Thomas VanDrunen Jens Palsberg Purdue University UCLA Computer Science Department Department of Computer Science 4531K Boelter Hall West Lafayette, IN 47907 Los Angeles, CA 90095 [email protected] [email protected] ABSTRACT tionality. This way we add behavior modularly. However, Multiple dispatching and the visitor pattern are approaches while introducing the benefit of functional programming to to making object-oriented programs more extensible. Both an object-oriented setting, we are also importing the liabil- have a flavor of pattern matching, thereby moving object- ity. Now we can no longer add classes easily. To use visitors oriented programming closer to functional programming. The for extension, we must in advance give each class an accept key idea of these approaches can be crystallized as a notion method (not to mention making sure that the visitor will of visitor which lies between functions and objects. Can have access to all internal data necessary for its task). More this idea be developed into a new form of visitor-oriented seriously, a visitor must know all the classes on which it will programming which combines the best of functional and operate [11]. The visit and accept methods are necessary object-oriented programming? As a first step, we present because using visitors is essentially using dynamic double a visitor calculus in which each value is a visitor and ev- dispatch| the correct method is selected based on both the ery visitor call uses double dispatching. We illustrate the acceptor's class and the visitor's class. Most object-oriented relationships to other paradigms by translating the lambda- languages support only single dispatch. calculus to the visitor calculus, and the visitor calculus to What we notice is that while a visitor is in fact an object, Java. Our calculus forms the core of a language in which we in a sense it can also be viewed as a function. A visitor is have programmed the translation of the lambda-calculus to related to both object-oriented and functional programming. the visitor calculus itself. To demonstrate the expressiveness We see a spectrum: of visitors, we show the translation in four versions that use Spectrum: function | visitor | object. smaller and smaller subsets of the language. Along the way, Is there a way we can exploit this approach to system build- we present correctness proofs and examples of running an ing so that we have the advantages of both paradigms, but implementation of our language. the disadvantages of neither? What we would like is a lan- guage designed specifically for programming with visitors, 1. INTRODUCTION where the visitor is the basic unit and the need for accept methods and precognition of acceptor classes is subsumed 1.1 Background by the language semantics, including rules for double dis- A program is a set of datatypes and a set of behaviors over patch. In other words, we would like a language where both cases of those datatypes. Maintaining a program requires datatypes and behaviors can be added modularly. extending the datatypes and their cases and extending the Various systems have been developed to study double dis- behaviors over them. We would like to to do this modu- patch and the visitor pattern. Millstein and Leavens [8] larly, that is, without recompiling the entire system each designed the Tuple language to show how to add multiple time an extension is made. This represents a well-known dispatch to conventional object-oriented languages cleanly, way of comparing programming paradigms and a dilemma letting the receiver of a method call be a tuple of objects in programming language design [12, 3, 7, 15]. In object- rather than a single object and selecting a method most spe- oriented languages, we can easily extend the datatypes by cific to those objects. If there is no appropriate method or writing new classes, including subclasses. Extending behav- no most specific method, such a call causes a message not ior, however, is difficult since methods are members of a understood or message ambiguous error, respectively. The class and so cannot be changed or added to without recom- second of these errors is a result of the dispatch being sym- piling that class. Functional programming takes the other metric. Generalizing to multimethods (any methods where side of the trade off. There, new functions on a datatype can dynamic dispatch depends on more than one argument), a be written and compiled separately, but once a datatype is multimethod is symmetric if all dispatching arguments are created, its cases are fixed. treated uniformly, that is, no argument has priority for de- The visitor pattern [5] is an attempt to solve this prob- termining an appropriate method. lem in an object-oriented paradigm; that is, it is a way Millstein and Chambers [9] presented Dubious, an object- to add functionality modularly without changing the set of oriented core language with symmetric multimethods. Du- datatypes. If we have a set of classes and determine that we bious uses a module system to reason about extensibility need new functionality for them, instead of adding a method and features a static type system which ensures that pro- to each and recompiling, we write a visitor class, with a grams that type check do not throw message not understood visit method for each class, which will perform that func- or message ambiguous errors. Functions are objects and thus are first-class. Similarly, Clifton, Leavens, Chambers, the way, we present correctness theorems and examples of and Millstein [2] presented MultiJava, also with symmetric running an implementation of Peripaton. multimethods, but with a class system like that of Java. A feature of MultiJava is the open class, a class to which 1.2.1 A visitor calculus methods can be added without changing the class directly. In our visitor calculus, each value is a visitor and every This offers an alternative to the visitor pattern in that new visitor call uses double dispatching. The grammar for Visi- functionality can be added to a class without the the prior Calc is as follows: planning needed to make infrastructure for visitors. In order to capture the flavor of the visitor pattern it- p ::= (c; e) programs self, double dispatching should be asymmetric| if a visitor e ::= expressions does not have a method that matches the class of an accep- (e e) invocations tor exactly but inherits a method that does, that method is j new t[e] creations chosen over a method it has which matches an ancestor class j x field references to the acceptor. Asymmetric semantics eliminates the pos- j acceptor parameter references sibility of a message ambiguous error since the precedence c ::= t : tfx; mg classes among arguments disambiguates the method selection. Fur- m ::= (t 7! e) method mappings thermore, a visitor class serving as an ancestor to all vis- A formal semantics will be presented in Section 3. For itors could contain a visit method for whatever class tops now, a VisiCalc program is a set of classes and a main ex- the class hierarchy (such as Object in Java; in a language pression. Each class defines a visitor type; a class definition designed specifically for visitors, this may be the visitor contains a name for the class, the class's parent, a list of class itself) and ensure no message will not be understood. fields, and a list of methods. Methods do not have names, which is convenient for a core calculus and formal reasoning but are identified by the type of a dispatching parameter (we since eliminating the possibility of the computation causing can think of each method having the name visit, and there an error allows us to focus on the computation itself. >From can be at most one such method for any parameter type). a practical software engineering point of view, symmetric The parameter is referred to by acceptor; intuitively, the double dispatching may be preferable; however, in this pa- callee or receiver of the method has a visitor, and the pa- per, we will pursue the asymmetric variant, to keep it close rameter is the acceptor. (One could easily reverse this and to the visitor pattern. call the methods \accept" and the parameter \visitor," if Dubious is classless but uses a module system that is good the reader finds that more in line with his experience with for what it formalizes|modules; a core calculus that focuses the visitor pattern.) on visitor behavior, however, would be more tractable with- When a method is called, (e1 e2), the method mappings out them and without the full programming language fea- for in the definition of e1's class are searched for a method tures of MultiJava. We would further like a calculus that can matching e2's type. If none are found, the methods of e1's be related to both functional and object-oriented paradigms parent class are searched, and so forth. If no appropriate by encodings among representative languages, demonstrated method is found among e1's class and all its ancestors, then by correctness proofs and implementations. we do a similar search for a method appropriate for e2's Castagna, Ghelli, and Longo [1] studied the λ&-calculus of parent class. This entire process will terminate because we overloaded functions with multiple dispatching. While mo- assume a pre-defined class visitor that is at the top of tivated by object-oriented programming, the λ&-calculus is the class hierarchy, as Object in Java, which has a method purely functional. In the λ&-calculus, an overloaded func- appropriate for any parameter, returning that parameter. tion is essentially a set of functions, and an overloaded- Here is the translation of the λ-term λx.x: function call uses dispatching via the types of its members.