We present a type and effect system for static analysis of programs written in a simplified version of iTasks. iTasks is a workflow specification language embedded in Clean, a general-purpose functional programming language. Given costs for basic tasks, our analysis calculates an upper bound of the total cost of a workflow. The analysis has to deal with the domain-specific features of iTasks, in particular parallel and sequential composition of tasks, as well as the general-purpose features of Clean, in particular let-polymorphism, higher-order functions, recursion and lazy evaluation. Costs are vectors of natural numbers where every element represents some resource, either consumable or reusable.

Abstract State-based interactive applications, whether they run on the desktop or as a web application, can be considered as collections of interconnected editors of structured values that allow users to manipulate data. This is the view that is advocated by the GEC and iData toolkits, which offer a high level of abstraction to programming desktop and web GUI applications respectively. Special features of these toolkits are that editors have shared , persistent state, and that they handle events individually. In this paper we cast these toolkits within the Arrow framework and present EditorArrow : a single, unified semantic model that defines shared state and event handling. We study the properties of EditorArrow , and of editors in particular. Furthermore, we present the definedness properties of the combinators. A reference implementation of the EditorArrow model is given with some small program examples. We discuss formal reasoning about the model using the proof assistant Sparkle . The availability of this tool has proved to be indispensable in this endeavor.

Task-Oriented Programming (TOP) is a novel programming paradigm for the construction of distributed systems where users work together on the internet. When multiple users collaborate, they need to interact with each other frequently. TOP supports the definition of tasks that react to the progress made by others. With TOP, complex multi-user interactions can be programmed in a declarative style just by defining the tasks that have to be accomplished, thus eliminating the need to worry about the implementation detail that commonly frustrates the development of applications for this domain. TOP builds on four core concepts: tasks that represent computations or work to do which have an observable value that may change over time, data sharing enabling tasks to observe each other while the work is in progress, generic type driven generation of user interaction, and special combinators for sequential and parallel task composition. The semantics of these core concepts is defined in this paper. As an example we present the iTask3 framework, which embeds TOP in the functional programming language Clean.

Workflow management systems (WFMS) are software systems that coordinate the tasks human workers and computers have to perform to achieve a certain goal based on a given workflow description. Due to changing circumstances, it happens often that some tasks in a running workflow need to be performed differently than originally planned and specified. Most commercial WFMSs cannot deal with the required run-time changes properly. These changes have to be specified at the level of the underlying Petri-Net based semantics. Moreover, the implicit external state has to be adapted to the new task as well. Such low-level updates can easily lead to wrong behaviour and other errors. This problem is known as the dynamic change bug. In the iTask WFMS, workflows are specified using a radically different approach: workflows are constructed in a compositional style, using pure functions and combinators as self-contained building blocks. This paper introduces a change concept for the iTask system where self-contained tasks can be replaced by other self-contained tasks, thereby preventing dynamic change bugs. The static and dynamic typing system furthermore guarantees that these tasks have compatible types.

The functional programming languages Clean and Haskell have been around for over two decades. Over time, both languages have developed a large body of useful libraries and come with interesting language features. It is our primary goal to benefit from each other's evolutionary results by facilitating the exchange of sources between Clean and Haskell and study the forthcoming interactions between their distinct languages features. This is achieved by using the existing Clean compiler as starting point, and implementing a double-edged front end for this compiler: it supports both standard Clean 2.1 and (currently a large part of) standard Haskell 98. Moreover, it allows both languages to seamlessly use many of each other's language features that were alien to each other before. For instance, Haskell can now use uniqueness typing anywhere, and Clean can use newtypes efficiently. This has given birth to two new dialects of Clean and Haskell, dubbed Clean* and Haskell*. Additionally, measurements of the performance of the new compiler indicate that it is on par with the flagship Haskell compiler GHC.

Workflow systems coordinate tasks of humans and computers. The iTask system is a recently developed toolkit with which workflows can be defined declaratively on a very high level of abstraction. It offers functionality which cannot be found in commercial workflow systems: workflows are constructed dynamically depending on the outcome of earlier work, workflows are strongly typed, and they can be of higher order. From the specification, a web-based multi-user workflow system is generated. Up until now we could only generate thin clients. All information produced by a worker triggers a round trip to the server. For real world workflows this is unsatisfactory. Modern Ajax web technology to update part of a web page is required, as well as the ability to execute tasks on clients. The architecture of any system that supports such features is complex: it manages distributed computing on clients and server which generally involves the collaboration of applications written in different programming languages. The contribution of this paper is that we integrate partial updates of web pages and client side task evaluation within the iTask system, while retaining its approach of a single language and declarative nature. The workflow designer uses light-weight annotations to control the run-time behavior of work. The iTask implementation takes care of all the hard work under the hood. Arbitrary tasks (functional programs) can be evaluated at web clients. When such a task cannot be evaluated on the client for some reason, the system switches to server side evaluation. All communication and synchronization issues are handled by the extended iTask system

In this paper we introduce the iTask system: a set of combinators to specify work flows in a pure functional language at a very high level of abstraction. Work flow systems are automated systems in which tasks are coordinated that have to be executed by humans and computers. The combinators that we propose support work flow patterns commonly found in commercial work flow systems. Compared with most of these commercial systems, the iTask system offers several advantages: tasks are statically typed, tasks can be higher order, the combinators are fully compositional, dynamic and recursive work flows can be specified, and last but not least, the specification is used to generate an executable web-based multi-user work flow application. With the iTask system, useful work flows can be defined which cannot be expressed in other systems: work can be interrupted and subsequently directed to other workers for further processing.The implementation is special as well. It is based on the Clean iData toolkit which makes it possible to create fully dynamic, interactive, thin client web applications. Thanks to the generic programming techniques used in the iData toolkit, the programming effort is reduced significantly: state handling, form rendering, user interaction, and storage management is handled automatically. The iTask system allows a task to be regarded as a special kind of persistent redex being reduced by the application user via task completion. The combinators control the order in which these redexes are made available to the application user. The system rewrites the persistent task redexes in a similar way as functions are rewritten in lazy functional languages.

Invertible programming occurs in the area of data conversion where it is required that the conversion in one direction is the inverse of the other. For that purpose, we introduce bidirectional arrows (bi-arrows). The bi-arrow class is an extension of Haskell's arrow class with an extra combinator that changes the direction of computation.The advantage of the use of bi-arrows for invertible programming is the preservation of invertibility properties using the bi-arrow combinators. Programming with bi-arrows in a polytypic or generic way exploits this the most. Besides bidirectional polytypic examples, including invertible serialization, we give the definition of a monadic bi-arrow transformer, which we use to construct a bidirectional parser/pretty printer.

Abstract Functional programming languages have banned assignment because of its undesirable properties. The reward of this rigorous decision is that functional programming languages are side-effect free. There is another side to the coin: because assignment plays a crucial role in Input/Output (I/O), functional languages have a hard time dealing with I/O. Functional programming languages have therefore often been stigmatised as inferior to imperative programming languages because they cannot deal with I/O very well . In this paper, we show that I/O can be incorporated in a functional programming language without loss of any of the generally accepted advantages of functional programming languages. This discussion is supported by an extensive account of the I/O system offered by the lazy, purely functional programming language Clean. Two aspects that are paramount in its I/O system make the approach novel with respect to other approaches. These aspects are the technique of explicit multiple environment passing , and the Event I/O framework to program Graphical User I/O in a highly structured and high-level way. Clean file I/O is as powerful and flexible as it is in common imperative languages (one can read, write, and seek directly in a file). Clean Event I/O provides programmers with a high-level framework to specify complex Graphical User I/O. It has been used to write applications such as a window-based text editor, an object based drawing program, a relational database, and a spreadsheet program. These graphical interactive programs are completely machine independent, but still obey the look-and-feel of the concrete window environment being used. The specifications are completely functional and make extensive use of uniqueness typing, higher-order functions, and algebraic data types. Efficient implementations are present on the Macintosh, Sun (X Windows under Open Look) and PC (OS/2).

Can functional programs be used to build real applications?The mere fact that this question is being asked is encouraging.Functional programming is all too often perceived as an exotic, mostly theoretical activity that has no bearing on reality.1994 saw two events specifically devoted to answering this question.The first was the Dagstuhl workshop on 'Functional programming in the real world', and the second the creation of this special issue.During the Dagstuhl workshop some 30 applications were presented.The call for papers for this special issue attracted 21 submissions.The sheer number of people working on applications indicates that solving real problems using functional languages is now becoming a serious proposition.The contributions in this issue address several diverse application areas: nuclear physics, databases query processing, parallel vision, building a spread sheet, solid modelling and molecular biology.Several other areas such as operational research and engineering design were represented in the papers that could not be included in this issue.A number of papers were also submitted targeting typical computer science applications, such as building parsers, programming environments, and executable specifications.The six papers that make up this issue have been selected purely on the basis of the formal refereeing process.Three of the papers describe prototypes of real systems.These are the database query processing, parallel vision and molecular biology systems.The production systems, which have been developed on the basis of these prototypes are used 'in anger'.The production systems have been implemented respectively as a shell script, a parallel Occam 2 program and as a C++ program.The prototypes are either incomplete, or too slow or space hungry to be used as a real application.The other three papers describe kernel applications, that were built to gain understanding of the problem domain.These are the nuclear physics, spreadsheet and solid modelling programs.These kernel applications are not used as real applications because they are not sufficiently complete to do the job properly.

Abstract This paper advocates the use functional programming languages for the formal specification of (abstract) machines. The presented description method describes machines by a two‐level model. At the bottom layer machine components and the micro instructions to handle them are described by using an abstract data type. The top layer describes the machine instructions in terms of these micro instructions. Using a functional language as specification language has several advantages. The abstraction mechanisms offered by a functional programming language are that good that one can abstract from irrelevant details as is required for a specification language. Functional languages have a well‐defined semantics such that the meaning of the specification is clear as well. Moreover, they offer the advantages of a programming language: the compiler can check the specification for partial correctness, eliminating for example type errors and unbound identifiers (errors which occur in many published descriptions). Furthermore, the specification can be executed such that one obtains a prototype implementation almost for free. Such an executable formal specification can, for instance, be used to investigate the dynamic behaviour of the described machine. For a simple machine, the proposed description method is compared with several other description methods: a traditional style, a denotational semantics and a formal specification in the language Z. To show that the proposed method is indeed useful to describe large and complicated machines, the method is applied for the specification of an abstract imperative graph rewrite machine (the ABC‐machine) which has been used in the construction of the compiler for the functional language Concurrent Clean.

A conceptual model is discussed which allows the hierarchic definition of high-level input driven objects, called input-output tools, from any set of basic input primitives. An input-output tool is defined as a named object. Its most important elements are the input rule, output rule, internal tool definitions, and a tool body consisting of executable statements. The input rule contains an expression with tool designators as operands and with operators allowing for sequencing, selection, interleaving, and repetition. Input rules are similar in appearance to production rules in grammars. The input expression specifies one or more input sequences, or input patterns, in terms of tool designators. An input parser tries, at run-time, to match (physical) input tokens against active input sequences. If a match between an input token and a tool designator is found, the corresponding tool body is executed, and the output is generated according to specifications in the tool body. The control structures in the input expression allow a variety of input patterns from any number of sources. Tool definitions may occur in-line or be stored in a library. All tools are ultimately encompassed in one tool representing the program.

InputInput tools, originally introduced as a language model for interactive systems and based on high-level, input-driven objects, have been developed into a model for communicating parallel processes, called the input tool process model (ITP).In this model every process contains an input rule, comparable to the right-hand side of a production rule.This rule specifies in an expression the patterns and sources of input it exPects and where the input is to be handled.The reception of the input triggers action inside the too! process.As part of the action, messages may be sent to other processes, with destination specified to a varying degree of identification.A potential candidate for a message is any tool process with the correct type of message slot.Because sending tool processes do not have to specify completely the identity of receiving tool processes, and vice versa, ITP provides a fully dynamic communication model.Most communication aspects of other recently developed models are contained in this model.Synchronization of processes is accomplished implicitly by the input specification; explicit synchro-nizatiQn constructs such as monitors and guarded regions can therefore be easily simulated.The ITP constructs provide a general concept for interprocess communication.Its application areas range from interaction via process control to operating systems.From a programming point of view, the language constructs offered are not in any way dependent on whether processes run on single or multiple processors.