We have shown that UHC is capable of supporting the development of complete client-side web applications, opening the door to Haskell-only web development. In the process we added the FEL to UHC and provided a library that exposes the JavaScript world to Haskell. Considering the increasing maturity of the GHC- based solutions, we can conclude that the two biggest contributions of this chapter are the FEL, and our evidence that writing a complete, non-trivial web application, optionally using external JavaScript libraries is now possible in Haskell. Since UHC does not support advanced Haskell language features, and GHC’s development is
11https://github.com/faylang/fay/wiki
12https://github.com/UU-ComputerScience/uhc-js/tree/benchmark
13https://github.com/osteele/functional-javascript
2.7. CONCLUSION faster and more consistent, it remains to be seen whether our implementation in UHC can grow to become a mature tool for developing JavaScript applications. While still keeping this option open, we also call on authors of GHC-based solutions to consider using the contributions of this chapter in their work.
When it comes to libraries for writing JavaScript applications in Haskell, better abstractions are still required to reduce the amount of code that lives in the IO monad directly, and to give programming with the UHC JavaScript backend a more functional feel. While performance, in most cases, is acceptable, it needs to be improved if computationally heavy functions are to be run on the client. In order for most of the frequently used Hackage libraries to be run on the client, additional work on UHC and Cabal will have to be performed.
Chapter 3
Tonic: A Graphical Representation of
Tasks
In Task Oriented Programming (TOP), tasks, as performed by both humans and computers, are the core concept. TOP is implemented by the iTask system (iTasks) as a shallowly embedded Domain Specific Language (DSL) in the functional pro- gramming language Clean. iTasks is used in industry for rapid prototyping in complex sociotechnical domains. However, for non-technical stakeholders, an iTask specification is too difficult to understand. Stakeholders like to communicate their ideas informally, using drawings and natural language, while TOP programmers model tasks in Clean. We propose a way to eliminate this communication gap by translating a textual iTasks specification into a graphical one, called a blueprint, which should be understandable by non-technical stakeholders. Blueprints abstract from Clean language details as much as possible, yet contain enough information to be understandable independently. Furthermore, we show how blueprints are instan- tiated at runtime, resulting in an animated trace, showing how end-users progress with which tasks. The Clean compiler has been adjusted to generate blueprints, as well as inject wrapper code that relates run-time information to the compile time specification. A Tonic viewer application, written in iTasks, uses this wrapper code to visualize the traces.
3.1
Introduction
Task Oriented Programming (TOP) [86] is a new style of functional program- ming intended for developing reactive web-based multi-user applications. It is implemented by the iTask system [84] (iTasks) as a Domain Specific Language, shallowly embedded in the strongly typed, lazy, purely functional programming language Clean [87]. TOP allows a programmer to focus on the high level speci- fication of the tasks that need to be done. One does not need to worry about the implementations details commonly faced when writing web applications. For ex- ample, GUI generation and handling, data storage and retrieval, persistency and the communication between the participating parties are all taken care of auto- matically. This is achieved by using advanced functional programming techniques such as type-driven generic programming [62, 8], uniqueness typing [15], and a hy- brid static/dynamic type system, which allows transferring and storing function applications [82]. With iTasks, developing reactive web-applications for support- ing collaboration on the Internet becomes equivalent to task modelling, giving all project stakeholders a common notion: the tasks that have to be performed by human beings and their computers.
One of the strengths of the system is its suitability for rapid prototyping. By defining di↵erent task models, one can study alternative, more efficient ways to let people and systems collaborate in complex and exacting settings. iTasks is being used in industry for this purpose. For example, it is used to prototype software for Crisis Management and Command and Control centres (see [69]).
Finding the best way of working together on tasks requires close collaboration between all stakeholders, such as managers, domain experts, and programmers. Multi-disciplinary collaboration is a well-known and hard challenge, due to the di↵erences in expertise and knowledge levels. But, since TOP applications can be defined at a high level of abstraction in terms of the common notion of tasks, it might become possible to bridge this classical communication gap. Doing so is not easy, however. A domain expert probably wants to define tasks informally, e.g., using a combination of natural language and diagrams of boxes connected by arrows (as used in BPMN [76, 77], for example). An iTasks programmer defines tasks textually in a precise, formal, mathematics-based notation (i.e. Clean). Most domain experts do not possess sufficient technical skills to define these tasks formally in Clean or to understand the code that programmers have written.
In this chapter we present Tonic: “Task-Oriented Notation Inferred from Code”. We aim to bridge the communication gap by o↵ering a common graphical lan- guage that both programmers and non-programmers can understand. The idea is twofold: on the one hand we generate a diagram of a program’s tasks, called a blueprint, from the formal iTasks specification. On the other hand, the same graphical notation can be used by non-programmers to convey their ideas using pen and paper.
A blueprint must strike a balance between showing the task structure at a sufficient level of detail on the one hand, without overwhelming non-programmers with details of programming in Clean on the other hand. We realize that it will take several design iterations of Tonic’s graphical syntax before the ideal balance is found. In this chapter we focus on the technical challenges that have to be solved to make Tonic possible.
A modified Clean compiler is used to generate blueprints1. Blueprints will not
only give insight in the tasks that have been defined statically, it will also be used to explain what goes on when tasks are being executed.
There are many challenges that have to be addressed. Firstly, tasks are func- tions. Representing functions graphically and predicting the exact order of evalu- ation in a lazy context are known to be hard problems in functional programming. However, tasks are functions that have result-type (Task a) and can therefore easily be distinguished from other functions. In addition, the task combinators have known and predictable monadic operational behaviour, making it possible to show how tasks depend on each other.
Secondly, the host language Clean, much like Haskell, o↵ers many language constructs. Since iTasks is a shallowly embedded DSL, any host language con- struct can be used to define tasks. Because blueprints must not overwhelm non- programmers with the details of programming in Clean, we have to carefully choose
1Ideally we would use a compiler API instead, but the Clean compiler’s architecture currently
3.2. SHORT OVERVIEW OF ITASKS