A domain-specific language, DSL is tailored to a specific application domain to facilitate the production and maintenance of programs. Functions add an important abstraction and repetition mechanism to DSLs, just as for any other programming language. For the evaluation of embedded DSLs one can use functions in the host language for this purpose. However, the automatic replacement of host function calls by their body is undesirable in other interpretations of the DSL, like pretty printing and code generation, especially for recursive DSL functions.

High-level languages are often implemented by transforming them into a stack-based intermediate language. To ensure correctness of the implementation, it is desirable to have a type-system for the stack-based code that ensures that the required arguments are available on the stack. This is quite challenging since the stack contains values of mixed types. Moreover, a single stack is shared by all basic stack instructions and the functions implemented with those instructions. Just like basic instructions, function calls are expected to replace their arguments by the result and to leave the rest of the stack untouched.

Internet of Things (IoT) software is notoriously complex, conventionally comprising multiple tiers. Traditionally an IoT developer must use multiple programming languages and ensure that the components interoperate correctly. A novel alternative is to use a single tierless language with a compiler that generates the code for each component and ensures their correct interoperation. We report a systematic comparative evaluation of two tierless language technologies for IoT stacks: one for resource-rich sensor nodes (Clean with iTask) and one for resource-constrained sensor nodes (Clean with iTask and mTask). The evaluation is based on four implementations of a typical smart campus application: two tierless and two Python-based tiered. (1) We show that tierless languages have the potential to significantly reduce the development effort for IoT systems, requiring 70% less code than the tiered implementations. Careful analysis attributes this code reduction to reduced interoperation (e.g., two embedded domain-specific languages and one paradigm versus seven languages and two paradigms), automatically generated distributed communication, and powerful IoT programming abstractions. (2) We show that tierless languages have the potential to significantly improve the reliability of IoT systems, describing how Clean iTask/mTask maintains type safety, provides higher-order failure management, and simplifies maintainability. (3) We report the first comparison of a tierless IoT codebase for resource-rich sensor nodes with one for resource-constrained sensor nodes. The comparison shows that they have similar code size (within 7%), and functional structure. (4) We present the first comparison of two tierless IoT languages, one for resource-rich sensor nodes and the other for resource-constrained sensor nodes.

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.

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.

Abstract The transition from imperative programming to functional programming for problems whose mathematical nature is not immediately obvious raises two questions. First, how can the function concept be applied to such problems, and, secondly, what language concepts are most suited in this situation. This paper shows that an existing functional programming language is very well suited for the elegant implementation of interactive programs. As an example, a text editor is described. The implementation of the editor has once more demonstrated the benefits of functional programming: fast generation of short and reliable programs. This indicates that it is worth while to investigate the application fields of functional programming languages as well as their implementation, in order to try to make them into general‐purpose programming languages that can be used in a production environment.