interactive media.virtual environments University of Hamburg

Visually Programming Arrows and Arrowized Functional Reactive Programming

Within the space of the FRVR project, the Haskell language and particularly the Arrow programming extensions play a crucial part of the new system. The FRVR system builds upon the Yampa (Arrowized Functional Reactive Programming) project, which is built in Haskell and relies heavily on the Arrow extensions. When using the system, it quickly becomes obvious that programming in the arrow style is difficult. The "syntactic sugar" of Paterson makes Arrow programming more accessible. Yet, coding meaningful systems is both conceptually difficult and at times tedious, due to carrying around all values as required in functional programming. When investigating the Dissertation of Courtney (AFRP’s main author) one sees illustrations to clarify the meaning of code and syntax. Even descriptions of the Arrow concept itself rely heavily on diagrams to explain how they behave, as seen below for the three functionalities of an arrow.

In the early development of the FRVR project, we found ourselves performing the same action, drawing diagrams for the reverse reason. The act of drawing diagrams of systems helped in understanding how to code them. Creating the diagrams solidified the concept of the program being created and made the structure of the Arrow based code more apparent. An example that is bit more complicated is show below, and is part of the Arrow website when explaining the Syntactic Sugar of Paterson:

This usage of diagrams suggests that a potentially useful approach would be to use visual programming for the programming of arrow based programming. Visual programming approaches have been used within the simulation communities to simplify programming for many years and is an integral part of their approach. The visual programming approach seems to be particularly advantageous in cases where the described process is of a data-flow nature. The >>> operator models precisely the data-flow nature. The Arrow and Yampa approaches correlate directly to this structure. Additionally, some work has been done on visual programming of functional languages and specifically Haskell code, but predate Arrows. While those have limited success, the arrow base programming paradigm lends itself much more readily to the visual programming paradigm.

This project focuses on creating a visual programming environment for arrow programming and specifically for the needs of programming Yampa. The resultant environment can be seen below in the screenshots of the application. The program is written in Java to allow better cross-platform usage. The basic functionality of the program allows the user to use all three of the basic arrow functionalities, though the 'first' functionality is handled through a slightly different mechanism or can be built by the user. The basic component of the visual programming environment is the arr functionality. The blue boxes shown in the screen shots each represent an arrow created by using the arr function. This diagram also shows how the 'first' function can easily be recreated by the user, here using the identity function to make this explcit. How this 'first' functionality works in the rest of the program is explained next.

In the diagram below we see several other features of the visual programming environment. The connections between Arrow boxes are simply the >>> function, routing the output of one function to the other. The redish boxes are a compound box. These boxes are a combination of other boxes, for instance the 'comp' Arrow below is the first functionality in the diagram above. As one can see here, we are using the lifting operator extensions, arr2 to arr8 to allow multi-input functions to be created, such as what the first expects, but doing it with primitives. The visual programming environment handles this internally, alleviating the user from having to do this manually. Also, in the image below we see that ArrowLoop is supported, allowing loops to be used in the visual programming environment.

Levels of the program code represent to SFs that in turn call internal SFs. Below we see a code fragment, along with the level which generates it. When "zooming out" a level, the code seen here is generated and displayed in the program window at the right hand side of the visual editing environment.

Additionally, as the goal of the project is to support programming of Yampa Signal Functions, several extensions are included. Signal Functions are instances of Arrows, so the basic functionality is already include. However, Yampa often relies on higher-level usage of SF. To this end, two further functionalities are included, both to use the SF as an object. The most common way this is used is in generating an SF via Haskell functions. For instance, the switch command takes various inputs including two SF. To achieve this in our system, a Haskell functions that produces a SF (i.e. can be used as the SF it generates) is required and a way to give SFs over as parameters. Below, we see how this is realized; In this example an SF being given over to a Haskell function, which is in turn in the graph.







Numerous other functionalities are necessary to make this a usable visual programming environment. For instance: the visual programming environment allows the user to save their modules and load them back in, including loading a portion of the saved environment back in. This enables the creation of libraries of often used elements. The export of the code is performed using the "Syntactic Sugar" style, so that the resultant code can be better understood and that the code better resembles the graphical representation.

People involved: