\Section{Tile Implementation} \label{sec:tile implementation} The macro system described in the previous section allows us to make any desired subset of a textual language available for viewing in graphical form. The textual code is parsed to create a parse tree. In this section, we describe the conversion to graphical tiles from the parse tree, as well as conversion in the opposite direction. \SubSection{Conversion To Graphical Tiles} For each macro application, the parser creates an instance of the JavaScript ``class'' {\tt Tile} that represents a node in the parse tree. There are different kinds of {\tt Tile} objects to represent different types of syntax nodes; we provide pre-made {\tt Tiles} for each basic JavaScript construct such as {\tt if}, {\tt while}, etc. so that these can be also represented visually. These different {\tt Tiles} delegate to a ``superclass'' called {\tt GenericTile}, which defines common behavior for all tiles; the specific tile types specialize this inherited behavior as appropriate. A method called {\tt makeTile()} is implemented by the {\tt Tile}s. In the TileScript implementation, this method escapes to underlying Smalltalk code that creates the graphical tile representation in the Morphic GUI framework. Since the tiles can be nested, {\tt makeTile()} is also called recursively to create nested graphical tiles. \begin{figure}[tp] \centering \scalebox{0.4}{\includegraphics{hypowhile.eps}} \caption{The appearance of {\tt while} statement with default look.} \label{fig:hypo while} \end{figure} \begin{figure}[tp] \centering \scalebox{0.4}{\includegraphics{realwhile.eps}} \caption{The appearance of {\tt while} statement with customized look.} \label{fig:real while} \end{figure} We could have used a single, universal, graphical representation for every macro, since all macros have the same structure (i.e., one parent and zero or more children nodes.) Figure \ref{fig:hypo while} shows a hypothetical visual of the {\tt while} statement in this generic way. The generic tile would be created with a list of sub-tiles, which would then be laid out in a simple manner. However, we would like to provide better looking, better-suited, and more distinctive, tiles for the most commonly used basic language constructs. For example, the graphical representation of {\tt while} actually looks like Figure \ref{fig:real while}. The specialized look of such a tile is created by hand in Morphic. Morphic provides a direct manipulation interface for creating and copying ``Morphs'' (``Morph'' is the basic graphic object in Morphic), for changing their size, color, border, etc., and most notably for embedding them into one another. By using this interface, we manually create a Morph structure that serves as the ``template'' for a particular tile. The tile designer may embed as many ``spacer'' Morphs, and other cosmetic Morphs, as he wishes, to lay things out nicely and to create precisely the appearance he prefers. He then needs to designate (via a menu) a morph to represent each ``hole'' to be filled by tiles dropped by the user during drag-and-drop tile scripting; each ``hole' Morph'' is subsequently marked with a distinctive Morphic ``property'' so that the TileScript system can know which morphs are to be replaced. In the case of {\tt while}, for example, there are two holes' to be marked, one for the boolean expression to be evaluated, and another for the statement(s) to be repeatedly executed. In the implementation of {\tt makeTile()} for a tile which has such a user-defined graphical tile template, the template is deeply copied and then the Morphs that represent the holes are replaced by the tiles that represent sub-trees. The end-user can easily use the same mechanism to create customized tiles to suit his personal taste. For {\tt repeat}, for example, the end-user would assemble Morphs and make a good-looking Morph with (more than) two submorphs. He would then identify two morphs (the iteration count and the body) via the UI. Once the user is happy with the look, TileScript stores the Morph as the new template for {\tt repeat}. Note that it is not strictly necessary to create a customized look for a user-defined tile; the generic tile can provide the same editing functionality. When a macro node in the parse tree contains a non-macro (i.e., textual) node, a special kind of tile that behaves as a text field is instantiated. The layout algorithm of these tiles (including the text field tile) is simple at this point and resulting morphs tend to be sparse when the user mixes textual code and tiles. Needless to say, the tile representation can be edited graphically. The user may obtain new tiles from any of the available templates, drag-and-drop them to construct a function, or delete tiles by dragging them out of structure, and he can type in expressions in the text fields. Each of the basic constructs in textual code (such as {\tt while}, {\tt if}, or a function application), has its own pre-defined macro. \SubSection{Conversion from Graphical Tiles} So far we have explained how to create a graphical representation from textual code that contains macros. To enable graphical editing by the user, we also need a way to convert the graphical representation back to a parse tree and to textual code. If we look at a graphical tile (represented as a Morph) in the script, there are submorphs that are marked as particular sub-nodes in a tree. The converter recursively looks at the sub trees in the Morph and converts them to parse trees. For a user-defined tile, the same macro definition can be used to do the conversion from tiles to the macro node. The macro specifies the name of tile, and the names (and numbers) of arguments. As long as the user marks the morphs that represent the sub-trees (provided as arguments) properly, the converter can visit the submorphs and convert them to partial parse nodes. Then, the parse node object for the user-defined tile itself is created with these sub-trees. Each parse node knows how to convert itself to textual code, which makes it possible for parse trees to be rendered as text. In the current implementation, the indentation and layout in the original text is lost even if the user were only to write some textual code, convert it to the tiles, and then go back to textual code without modifying the tiles; we are planning to add more attributes to parse tree nodes so that properties such as comments, indentation levels, and positions in the original source code are preserved when possible. \SubSection{Conversion from Base JavaScript to Macros} It is also useful to be able to convert arbitrary textual code written in the base JavaScript language (i.e., without macros) to the form with macros. To do this, we provide a macro definition for every JavaScript construct. The definition of {\tt @if} above is an example of such a macro. By running a visitor that converts JavaScript constructs to macros, one can convert the textual JavaScript code to tiles.