Customization of Visualizations in a Functional Programming Environment

Transcription

1 Customization of Visualizations in a Functional Programming Environment J. Ángel Velázquez-Iturbide and Antonio Presa-Vázquez Escuela Superior de Ciencias Experimentales y Tecnología Universidad Rey Juan Carlos C/ Tulipán s/n, Móstoles, Madrid, Spain Abstract CS first-year students expect the user interface of programming environments to be similar to that of common PC applications. A natural evolution of educational programming environments consists in incorporating many of their userfriendly facilities. We concentrate in this paper on the facilities that WinHIPE, an environment for functional programming, provides to students for customizing the visualization of expressions. Expressions can be either pretty-printed as text or displayed graphically, showing drawings of lists and binary trees. Besides, fonts, sizes, colors, lines and distances are parameters that can be customized for any visualization. Finally, the visualization of large expressions can be simplified to show only their most relevant parts. Students obtain several benefits from customization facilities. They feel more comfortable with the programming environment WinHIPE, because they can develop more readable programs, written in their personal style. Students can also experiment at small effort with different formats, becoming profident in style issues. Finally, customization facilities allow making clear in a course on programming languages the relevant role of visualizations in programming tools and their relative independence from language syntax. Introduction A good user interface for an educational programming environment must fulfil a series of requirements. The programming tools it integrates must provide the student with mental models consistent with those given in the classroom. It should also give a comprehensive assistance for errors. The user interface must be user-friendly; at least, it must meet the standards of commercial applications. In addition, other facilities for educational uses (tutoring, assessing, etc.) should also be provided. Professional programming environments often do not meet all of these requirements. The situation is worse that expected: computer scientists build complex, user-friendly programs, but they typically use complex programs (programming environments and tools) with poor user interfaces. Despite the consensus about the importance of program readability and the great improvements in programming environments in the last two decades, they are under the quality standards of commercial applications. This situation can be successfully managed by professionals, but it is completely unsatisfactory in an educational setting. Students who face programming environments for the first time do not compare them with other programming environments, but with other common applications, such as word processors, Web browsers, games, etc. If the interaction with the programming environment is not userfriendly, the student gets the wrong idea that computer science is too hard, boring or uninteresting. Moreover, if the student goes on, he/she can think that user interfaces are not an important part of programs. We concentrate in this paper on a facility that can make a programming environment user-friendly with respect to a very important part of its human-computer interaction: visualizations of programs. There have been many contributions related to this topic: pretty-printing in text editors [6] and syntax-directed editors [8], program visualization [9], documentation of programs [4], and application of typography to programs [1]. However the interaction with these systems is far from satisfactory: it is usually made in a batch fashion and it is isolated from common programming tools such as compilers and debuggers. Our claim is that visualizations should be as easily customizable as in commercial applications. (For instance, word processors allow to use different typographic styles for text by modifying font, size, color, etc. of characters.) We have implemented customizable graphical facilities in order to satisfy these goals in an educational environment for functional programming, called WinHIPE. As far as we know, the features included are original with respect to other programming environments. The integration and flexible use of ortogonal graphical facilities produces an synergetic effect in its effective use. The structure of the paper follows. The second section describes briefly the main features of WinHIPE. The third section contains the main contribution of the paper, three kinds of opportunities for customizing program visualizations: textual vs. graphical visualizations, typographic styles, and simplification of very large visualizations. Section 4 contains a discussion about the main benefits obtained from customizing visualizations. Finally, our main conclusions are included. 12b3-22

2 A functional programming environment: WinHIPE WinHIPE is the Windows version of a programming environment for the functional language Hope [2] (HIPE stands for Hope Integrated Programming Environment). On attempting to teach typed funcional programming, we found out that, although there were very good implementations, their corresponding environments were very poor, and inadequate for education. HIPE was designed according to the following design decisions [10]: Availability and integration of several programming tools (at least, an editor and an interpreter). Although this seems to be a trivial statement, the environments we found for modern functional languages were a simple shell with a command line to interact with the language processor, the file system, and little more. Graphical user interface, based on windows, menus and the mouse. High-level debugger. It should provide with mechanisms to control the progress of expression evaluation, based on an operational semantics of the language. The view of such an operational semantics should be consistent with the theoretical model given at the classroom. We have developed several versions of HIPE, being WinHIPE the latest [7]. The main features of WinHIPE can be better understood with the well-known factorial function. It can be defined in Hope as follows: dec fact: num -> num; --- fact n <= if n=0 then 1 else n*fact(n-1); This definition can be used to evaluate functional expressions involving the factorial function. A visualization of the step-by-step evaluation of the factorial of four follows: fact 4 if 4=0 then 1 else 4*fact(4-1) if false then 1 else 4*fact(4-1) 4*fact(4-1) 4*fact(3)... 4*(3*(2*(1*fact 0))) : num We can summarize the facilities that WinHIPE offers: Graphical user interface. It includes the typical components in Windows applications: menus and dialogs, buttons bar, files handling, multiple editing windows, and interactive help. Projects. The programmer can handle projects, which are groups of files. Their interest is educational, since a project allows clustering the files developed for one assignment, e.g. a file with the source code, another one with the expressions used for testing and others with traces of their evaluations. High level debugging of functional programs. As the previous example illustrated, WinHIPE models the evaluation of expressions as a rewriting process, showing the programmer the intermediate expressions she requests. The programmer can control evaluation in two different ways. First, she can select either eager or lazy evaluation strategy. Second, the advance in the evaluation can be controled according to five possibilities: one rewriting step, n rewriting steps, to evaluate the redex, to evaluate the whole expression, and to evaluate until achieving a breaking point. (The redex or reducible expression is the next subexpression to be rewritten or reduced.) Visualization of functional expressions. The programmer can choose several formats for the visualization of functional expressions, which are described in more detail in the following section. These and other customizable decisions can be kept in configuration files. Correction and assessment of assignments. WinHIPE gives some basic services for managing and correcting assignments based on program testing. These services are designed to be offered in a networked environment under protocol TCP/IP. The environment is being used since the academic year 1998/99 in a freshman course on programming languages, allowing to focus on the functional paradigm as a way of introducing both a programming language and programming language concepts. Customization of visualizations The environment allows the programmer to customize the visualization of intermediate expressions resulting during any evaluation. We want to remark that an important decision was that the environment must always show the whole expression, in order to know the current state of the evaluation. Customization can be done in three different but related ways. First, the programmer can select a graphical or a textual visualization of expressions. Second, the format of a visualization can be tailored with many parameters. Finally, long expressions can be shortened, showing the parts most relevant to understand the evaluation state. 12b3-23

3 Text versus graphics The usual format for showing expressions is textual. Expressions are unparsed in a text window, pretty-printed to make them as readable as possible. Some examples of textual expressions resulting during the computation of fact 4 were included in the previous section. The textual presentation of expressions is natural for many problems, for instance mathematical problems. In addition, functional languages provide predefined and readable notations for simple data structures, such as tuples and lists. For instance, (0,4,true) is a 3-tuple which contains two integers and a boolean value. The expression [3,5,7,11] denotes a list containing four prime numbers, and abc denotes a list of characters with three letters. However, the situation changes when other data structures are involved. A data type definition for polymorphic binary trees follows: data TREE(alpha) == Empty ++ Node(TREE(alpha)#alpha#TREE(alpha)); where alpha stands for any data type. Given this definition, we can write expressions denoting binary trees. For instance, a tree containing four prime numbers can be represented as: Node (Node (Empty, 5, Empty), 3, Node(Node(Empty, 11, Empty), 7, Empty)) Notice that trees are much less readable than the data structures above. Anyway, we have written it with an indentation that facilitates its comprehension (it is similar to its graphical representation, rotated 90º to the left). The comprehension of more complex expressions, with trees, function applications, conditionals, etc. is more difficult. A remedy for this unreadability is to provide a graphical representation for data structures. We have decided to visualize graphically lists and binary trees [5]. The interest of the graphical visualization for trees is clear. With respect to lists, it is not so important for simple expressions, but a graphical representation increases the comprehension of complex expressions involving lists. We begin with two simple displays in Fig. 1, corresponding to a the list [3,5,7,11] and the tree above. The list representation is simply a sequence of its elements, with a small overlapping between consecutive elements. The tree representation is based on the following aesthetic criteria [12], similar to those in textbooks: All the nodes at the same depth in a tree are drawn at Figure 1. Visualization of a list and a tree the same level A node is drawn centered over its children Identical trees are drawn identical Symmetric trees are drawn symmetric In addition, empty trees are omitted for simplicity. The situation is more complicated for more complex expressions. The following function computes the mirror of a tree: dec mirror: TREE(alpha) -> TREE(alpha); --- mirror Empty <= Empty; --- mirror (Node(lt,x,rt)) <= Node(mirror(lt),x,mirror(rt)); Figure 2 corresponds to an expression that will compute the mirror of a binary tree. It is not a pure graphical format, but a mixed format, composed of text and graphics, that allows to represent easily arbitrary expressions: lists and trees are represented graphically, but other expressions (e.g. function application or the conditional expression) are Figure 2. An expression involving a tree 12b3-24

4 represented by text. Figure 3 shows the first expression resulting from applying the function mirror. This figure is more complex, with three kinds of rectangles used for different elements of the graphical representations of a tree: must still be inserted. The second figure shows the expression resulting after one rewriting step. Figure 3. Another expression involving a tree 1. A rectangle with a thick solid line represents a node of the binary tree. Technically, it is an expression with the pattern Node(_,_,_), obviously of type TREE(_). 2. A rectangle with a thin solid line represents a subtree whose shape is still unknown, i.e. a subtree that is not necessarily restricted to a single node. Technically, it is an arbitrary expression of type TREE(_). 3. A rectangle with a dotted line encloses a graphical representation of a tree. It is drawn when there is a switch from a textual visualization to the inner graphical one, thus easing to relate the tree with its enclosing expression. Technically, it is the same situation as in the first case, but the enclosing expression is different from Node(_,_,_). Similar rectangles are provided for lists. For example, the following function sorts lists by direct insertion: dec insert: num#list(num) -> list(num); --- insert (e,[]) <= [e]; --- insert (e,x::l) <= if e < x then e::(x::l) else x::insert(e,l); dec insertsort: list(num) -> list(num); --- insertsort [] <= []; --- insertsort (x::l) <= insert(x,insertsort(l)); The two expressions visualized in Fig. 4 are obtained on evaluating the expression insertsort[1,6,4,3]. The first one shows an expression where the two last elements of the original list are sorted, and the two first Figure 4. Two expressions involving lists The example shows that there are two rectangles for representing visually different elements of a list: 1. A rectangle with a thick solid line represents an element. 2. A rectangle with a thin solid line at the right side of a visualization of a list represents a sublist whose value is not known yet, i.e. it is an arbitrary expression of type list(_). WinHIPE allows students choosing the visualization format they prefer, either pure text or the mixed textualgraphical format. The choice is made by simply selecting the corresponding option in a dialog window. The programmer can even switch between both formats at any moment of an evaluation and as many times as she wants. Typographic styles A student using WinHIPE not only can visualize expressions in a textual or a mixed format, but she can customize many of its typographic features. Customization is achieved by tuning several parameters: The environment differentiates among several classes of windows capable of containing text, which can be given different background color, as well as font, font style and size of characters. The windows are customized with the same dialogs used in word processors to give formats. The redex can be highlighted by visualizing it in a color different from the color of the rest of the expression. This customization is made with a dialog equal to the previous one. This option is activated in the figures included in the paper, showing the redex in gray, rather than black. Textual visualization of functional expressions can be pretty-printed in user-defined ways. The programmer can define the textual format of every kind of expression. This customization is made by demonstration, with the user freely inserting line breaks, spaces and tabulators in 12b3-25

5 a template. The user can customize any part of an expression but its subexpressions, which are invariant parts of the expression. The specified format will write every part of the conditional expression in a different line and with the same indentation. The text produced for the conditional expression included above to compute the factorial of four is: if 4 = 0 then 1 else 4 * fact (4-1) An interesting feature is to allow pretty-printing expressions in a syntax forbidden in the programming language, but that the programmer considers to be readable. (As this is a dangerous feature, when the switch over the template is on, the consistency of the template with the language syntax is checked and thus enforced.) For instance, the same conditional expression, pretty-printed imitating Modula-2 is visualized as: IF 4 = 0 THEN 1 ELSE 4 * fact (4-1) END Graphical visualizations of lists and trees can be customized in any distance or typographic feature. In fact, the styles of lines described in the previous subsection are just the styles specified in the predefined configuration of the environment, but the programmer can freely modify them. The configurable elements for a list visualization are: distance between text and element border, overlapping between consecutive elements, and whether elements will have round corners. The empty list is drawn as special circular cell, whose radius can be defined. The configurable elements for a tree are: distance between text and node border, distance between nodes at the same level, distance between nodes at consecutive levels, whether nodes or subtrees have round corners, whether all the nodes or subtrees at the same level have the same height, and whether degenerate trees are drawn vertically or in diagonal. Empty trees are considered special trees which can be drawn square or round. The expression visualized in the second figure is visualized again in Fig. 5 with a different typographic style. Simplification of visualizations Figure 5. Another visualization of the second tree expression A visualization problem arising with non-trivial programs is the scaling problem: expressions can be too large to be easily understood, and even to fit in a window. Some mechanism must be provided to cope with large amounts of information. We provide a solution for the scaling problem with the technique known as fisheye views [3]. A fisheye view distorts a visualization, showing the most relevant parts and hiding the less important ones. The resulting visualization preserves a balance between global context given by the whole structure and the focus of interest. We have adapted the fisheye view technique to simplify the visualization of functional programs [11] in the following way. We can imagine a functional expression to be represented by its abstract syntax tree (AST). Global context is given by the whole expression, so the closer a subexpression to the root of the AST, the more interesting the subexpression. The local focus of interest is given by the next subexpression to rewrite, i.e. the redex. As a consequence, the most interesting part of an expression is the path along its AST that links the root and the redex. Given this definition of the most important part of an expression, we need a simple way to control the amount of information to visualize. The minimum visualizable part would be just the path between the root and the redex. We can show more parts of the expression by visualizing slices around the path. A number allows the programmer to state the desired number of visible slices. We can illustrate the technique with an example. Let us consider the following expression again: if 4=0 then 1 else 4*fact(4-1) where we have highlighted the redex. With an appropriate number (here, greater than or equal to 4), the whole expression is visualized. However, as the programmer reduces such a number to 3, 2, 1, and 0, the visualization is being simplified as follows: 12b3-26

6 if 4=0 then 1 else 4*fact( ) if 4=0 then 1 else 4*fact... if 4=0 then 1 else...*... if 4=0 then... else... Acknowledgments This work was partially supported by the Comunidad Autónoma de Madrid with project no. 07T/0036/98 Notice that the most relevant part for the current state of the computation (i.e. the condition) is preserved, and more distant parts, are successively hidden. The fisheye view technique is general and independent from the particular display format, so both textual and graphical visualizations can be simplified. Figure 6 shows a simplification of our tree. Benefits of customizations Programmers in general, and students in particular, obtain several benefits from customization facilities integrated in WinHIPE. The most evident advantage is that students feel more comfortable with the programming environment. This comfort comes from three facts. First, readability of programs is enhanced. Second, they feel to be using state-of-the-art software, as user-friendly as commercial applications. Third, they can develop programs in their personal style. Students get interested in style issues since they can experiment at small effort with different formats. Therefore, they quickly become profident in style matters and do not observe style as a personal taste of the teacher. WinHIPE is currently being used in a course on programming languages, and its customization facilities also allow us illustrating some concepts during the course. In particular, they allow us making clear the relevant role of visualizations in programming tools and their relative independence from language syntax. Students study the programming language with pure text syntax, but they are also given the equivalent, graphical representations. Conclusions We have shown the visualization facilities in a functional programming environment, WinHIPE, with especial emphasis on facilities for customizing them. They fit in three categories: textual vs. graphical visualizations, typographic formats, and scaling of visualizations. We have also described some of the advantages that customizations provide in a subject on programming languages. We think that, given the current state of the art in visualization, programming language processing and programming environments, it is not too difficult to include facilities such as those described here in educational environments. Clearly, this is one of the most promising lines of research and development for educational uses. Figure 6. Simplification of the second tree expression References [1] Baecker, R.M., Marcus, A., Human Factors and Typography for More Readable Programs, ACM Press, 1990 [2] Burstall, R., MacQueen, D., Sanella, D., HOPE: An experimental applicative language, The 1980 LISP Conference, pp [3] Furnas, G.W., Generalized fisheye views, ACM SIGCHI 86 Conference on Human Factors in Computing Systems, pp [4] Knuth, D.E., Literate programming, The Computer Journal, Vol. 27, No. 2, May 1984, pp [5] Jiménez-Peris, R., Pareja-Flores, C., Patiño-Martínez, M., Velázquez-Iturbide, J.Á., Graphical visualization of the evaluation of functional programs, SIGCSE/SIGCUE Conference on Integrating Technology into Computer Science Education (ITiCSE'96), June 1996, pp [6] Oppen, D.C., Prettyprinting, ACM Trans. on Programming Languages and Systems, Vol. 5, No. 4, October 1983, pp [7] Presa-Vázquez, A., WinHIPE: un entorno educativo de programación funcional para Windows, Master s Thesis, Facultad de Informática, Universidad Politécnica de Madrid, January 1999 [8] Rubin, L.F., Syntax directed pretty-printing A first step towards a syntax-directed editor, IEEE Trans. on Software Engineering, Vol. SE-9, No. 2, March 1983, pp [9] Stasko, J., Domingue, J., Brown, M.H., Price, B.A. (eds.), Software Visualization, The MIT Press, b3-27

7 [10] Velázquez-Iturbide, J.Á., Improving functional programming environments for education, in Man- Machine Communication for Educational Systems Design, M.D. Brouwer-Janse and T.L. Harrington (eds.), Springer- Verlag, 1994, pp [11] Velázquez-Iturbide, J.Á., Automatic simplification of the visualization of functional expressions by means of fisheye views, Joint Conference on Declarative Programming (AGP 98), July 1998, pp [12] Walker II, J.Q., A node-positioning algorithm for general trees, Software Practice and Experience, Vol. 20, Nº. 7, July 1990, pp b3-28