using conjunction and disjunction operators.
5.5
Blueprints for All
In the previous sections we have looked in great detail at the way Tonic is im- plemented for iTasks programs. One of the claims we have made earlier is that we now support blueprints for any monad. To solidify this claim, we shall look at an example of dynamic blueprints of a program in the IO monad. Showing a dynamic blueprint for non-iTasks programs requires a new Tonic viewer, which we will discuss as well.
5.5.1
Dynamic Blueprints of the I/O Monad
Lets look at how Tonic handles the IO variant of the primeCheck example. Fig- ure 5.30 shows the dynamic blueprints for primeCheck. This dynamic blueprint is produced by an experimental stand-alone Tonic viewer, which serves as a proof- of-concept that such a stand-alone viewer can be constructed. As such, we are currently limited in the kind of information that we can dynamically show. The next section will elaborate on the implementation of the stand-alone viewer and talk about how the Tonic classes are implemented for the IO monad. We will also discuss some of the challenges we have encountered.
io_examples.primeCheck :: IO () (1-0)
putStrLn (1-1)
"Enter number:" getLine (1-2) numStr
putStrLn
"Entered: " +++ numStr isPrime (toInt numStr)
True putStrLn "Is prime: " +++ numStr
False putStrLn
"Isn't prime: " +++ numStr
(a)
io_examples.primeCheck :: IO () (1-0)
putStrLn (1-1)
"Enter number:" getLine (1-2) numStr
putStrLn (1-3)
"Entered: " +++ numStr isPrime (toInt numStr)
True putStrLn "Is prime: " +++ numStr
False putStrLn (1-4)
"Isn't prime: " +++ numStr
(b)
Figure 5.30: Dynamic blueprint for IO variant of primeCheck.
Creating a general (i.e. iTasks-agnostic) stand-alone viewer largely requires solving the same problems as for writing an embedded viewer: how does one load and draw the blueprints? How does one receive and process dynamic updates? How does one inspect dynamic data? It turns out that these questions become significantly more challenging when answering them for a general and stand-alone Tonic viewer. We will look at these aspects next.
5.5.2
Stand-alone Viewer Architecture
Instead of including the Tonic viewer as part of an iTasks program, the stand-alone viewer communicates with the to-be-inspected program via TCP. Figure 5.31 shows its architecture. There is a two-way communication channel between the original application (the server) and the Tonic viewer (the client).
Stand-alone Tonic viewer Annotated program
Tonic state Annotated
tasks Write meta-data
Tonic viewer Read meta-data Non-annotated
tasks Other functions and types
On-disk blueprints
Read blueprint
Send meta-data Tonic server
Blueprint server
Request blueprint Send blueprint
Figure 5.31: Architecture of the stand-alone Tonic viewer
Blueprints are stored on disk in the same directory as the application for which they are generated. This allows the embedded Tonic viewer to locate them. The stand-alone viewer is not necessarily located in the same directory as the program that needs to be inspected, however. As a result, it cannot access the blueprints di- rectly. Instead, it requests blueprints from the server and caches them, after which they can be drawn. The stand-alone viewer uses the same drawing mechanism as the built-in viewer.
Dynamic updates are provided by the Tonic wrappers. In the iTasks imple- mentation, these wrappers write directly to the Tonic SDS. Wrappers for the stand-alone viewer write to a TCP connection instead. On the client-side, this data is stored again in an SDS.
5.5.3
Drawing Dynamic Blueprints
Figure 5.32 shows the protocol the Tonic viewer uses to instantiate blueprints and update them. When starting the client, it connects to exactly one server. The server registers the client, so it knows it can send updates to it when the program is executed. These updates are received by the client. If a given blueprint instance does not exist yet, the client tries to instantiate it. If the blueprint is not available on the client yet, it requests it from the server. Finally, the blueprint instance is updated and the client waits for the next update.
In the integrated Tonic viewer, blueprints are identified by a task’s unique identifier. In the stand-alone viewer, we abstract over this identifier by allowing it to be anything for which equality is defined. It is up to the implementation of the Blueprint and Contained classes to determine what the identifier is.
Inspecting values at run-time is another challenge in the stand-alone Tonic viewer. In the integrated viewer, we simply imposed the iTask constraint on any-
5.6. RELATED WORK Client Receive Updates Server Register Client Connect to Server Send Updates Receive Update Has
Blueprint? Request Blueprint Load Blueprint Send Blueprint Receive Blueprint Cache Blueprint Load Blueprint Has Blueprint Instance? Instantiate Blueprint Load Blueprint Instance
Update Blueprint Instance Yes
No
Yes
No
Figure 5.32: Client/server protocol for the stand-alone Tonic viewer.
thing that could be inspected, allowing rich visualizations. In general, we cannot rely on this constraint being fulfilled. In the stand-alone viewer, we therefore currently disallow inspection of run-time values. One could take a first step to- wards dynamic value inspection by, for example, impose JSON (de)serialization constraints. Inspecting raw JSON data structures quickly becomes unwieldy for complex data structures, however.
5.5.4
Discussion
A clear downside to the approach presented above is that for each monad for which one wants to have dynamic blueprints, one needs to implement a blueprint server. The current implementation of the stand-alone Tonic viewer also has sev- eral limitations. It is currently not possible to inspect values or do dynamic branch prediction, nor is it possible to select which blueprint instance you are interested in; the viewer only ever shows the blueprint instance for which the latest update arrived. Still, we feel like this is an important step towards positioning Tonic as a general tool.
5.6
Related work
Tonic can be seen as a graphical tracer/debugger. Several attempts at tracer/de- buggers for lazy functional languages have already been made. Some examples include Freja [74, 73], Hat [95, 96], and Hood [10], the latter of which also has a graphical front-end called GHood [90]. All of these systems are general-purpose and in principle allow debugging of any functional program at a fine-grained level. Tonic only allows tracing on a monadic abstraction level. Due to our focus on
monads, Tonic does support any monad, including the IO monad. All of the aforementioned systems only have limited support for the IO monad. Freja is im- plemented as its own compiler which supports a subset of Haskell 98. Previous Hat versions were implemented as a part of the nhc98 compiler. Modern Hat versions are implemented as stand-alone programs and support only Haskell 98 and some bits of Haskell 2010. Tonic is implemented in the Clean compiler and supports the full Clean language, which is more expressive than even Haskell 2010. Hood, on the other hand, requires manually annotating your program with trace functions. GHood is a graphical system on top of Hood that visualizes Hood’s output. Its visualizations are mostly aimed at technical users. Graphical programming language, such as VisaVis [88] and Visual Haskell [89] su↵er from similar problems. Tonic explicitly aims at understandability by laymen by choosing a higher level of abstraction, hiding details that do not contribute significantly to understanding the program, and by utilizing coding conventions.
Another way to look at Tonic is as a graphical communication tool. In a way, it is similar to docblock-like technologies, such as Javadoc4, in which documentation
is included in the comments in the code. Docblocks are typically used to generate textual API documentation, rather than comprehensive graphical representations. In another way, Tonic is similar to UML [76, 77] and BPMN [105]. Both of these technologies also o↵er a means to specify programs and workflows. This is something Tonic is not designed to do. Previous work from our group, GiN – Graphical iTasks Notation [53] can be used for that.