-@PREAMBLE{ {\providecommand{\noopsort}[1]{}} }
+@PREAMBLE{ {\providecommand{\noopsort}[2]{#2} } }
@inproceedings{suchocki_microscheme:_2015,
address = {Washington DC, USA},
series = {{CS} {Techreport} 718},
abstract = {Clean is an experimental language for specifying functional computations in terms of graph rewriting. It is based on an extension of Term Rewriting Systems (TRS) in which the terms are replaced by graphs. Such a Graph Rewriting System (GRS) consists of a, possibly cyclic, directed graph, called the data graph and graph rewrite rules which specify how this data graph may be rewritten. Clean is designed to provide a firm base for functional programming. In particular, Clean is suitable as an intermediate language between functional languages and (parallel) target machine architectures. A sequential implementation of Clean on a conventional machine is described and its performance is compared with other systems. The results show that Clean can be efficiently implemented.},
booktitle = {Functional {Programming} {Languages} and {Computer} {Architecture}},
publisher = {Springer Berlin Heidelberg},
- author = {Brus, T. H. and {\noopsort{Eekelen}van Eekelen}, M. C. J. D. and {\noopsort{Leer}van Leer}, M. O. and Plasmeijer, M. J.},
+ author = {Brus, T. H. and \noopsort{Eekelen}{van Eekelen}, M. C. J. D. and \noopsort{Leer}{van Leer}, M. O. and Plasmeijer, M. J.},
editor = {Kahn, Gilles},
year = {1987},
pages = {364--384},
volume = {1},
booktitle = {{PARLE}, {Parallel} {Architectures} and {Languages} {Europe}},
publisher = {Springer Verlag},
- author = {Barendregt, H.P. and {\noopsort{Eekelen}van Eekelen}, M.C.J.D and Glauert, J.R.W. and Kennaway, J.R. and Plasmeijer, M.J. and Sleep, M.R.},
+ author = {Barendregt, H.P. and \noopsort{Eekelen}{van Eekelen}, M.C.J.D and Glauert, J.R.W. and Kennaway, J.R. and Plasmeijer, M.J. and Sleep, M.R.},
year = {1987},
pages = {159--174},
file = {barh87-Lean.ps.gz:/home/mrl/.local/share/zotero/storage/63FBHND7/barh87-Lean.ps.gz:application/gzip;barh87-Lean.ps.gz:/home/mrl/.local/share/zotero/storage/6H2UKQGZ/barh87-Lean.ps.gz:application/gzip},
shorttitle = {Exchanging sources between {Clean} and {Haskell}},
number = {11},
journal = {ACM Sigplan Notices},
- author = {{\noopsort{Groningen}van Groningen}, John and {\noopsort{Noort}van Noort}, Thomas and Achten, Peter and Koopman, Pieter and Plasmeijer, Rinus},
+ author = {\noopsort{Groningen}{van Groningen}, John and \noopsort{Noort}{van Noort}, Thomas and Achten, Peter and Koopman, Pieter and Plasmeijer, Rinus},
year = {2010},
pages = {49--60},
file = {groj10-Haskell_front_end_Clean.pdf:/home/mrl/.local/share/zotero/storage/WVZWX8WT/groj10-Haskell_front_end_Clean.pdf:application/pdf},
doi = {10.1017/S0956796802004574},
number = {3},
journal = {Journal of Functional Programming},
- author = {Elliott, Conal and Finne, Sigbjørn and {\noopsort{Moor}de Moor}, Oege},
+ author = {Elliott, Conal and Finne, Sigbjørn and \noopsort{Moor}{de Moor}, Oege},
year = {2003},
note = {Publisher: Cambridge University Press},
pages = {455--481},
title = {Clean {Language} {Report} version 3.1},
urldate = {2021-12-22},
institution = {Institute for Computing and Information Sciences},
- author = {Plasmeijer, Rinus and {\noopsort{Eekelen}van Eekelen}, Marko and {\noopsort{Groningen}van Groningen}, John},
+ author = {Plasmeijer, Rinus and \noopsort{Eekelen}{van Eekelen}, Marko and \noopsort{Groningen}{van Groningen}, John},
month = dec,
year = {2021},
pages = {127},
abstract = {Concurrent Clean is an experimental, lazy, higher-order parallel functional programming language based on term graph rewriting. An important difference with other languages is that in Clean graphs are manipulated and not terms. This can be used by the programmer to control communication and sharing of computation. Cyclic structures can be defined. Concurrent Clean furthermore allows to control the (parallel) order of evaluation to make efficient evaluation possible. With help of sequential annotations the default lazy evaluation can be locally changed into eager evaluation. The language enables the definition of partially strict data structures which make a whole new class of algorithms feasible in a functional language. A powerful and fast strictness analyser is incorporated in the system. The quality of the code generated by the Clean compiler has been greatly improved such that it is one of the best code generators for a lazy functional language. Two very powerful parallel annotations enable the programmer to define concurrent functional programs with arbitrary process topologies. Concurrent Clean is set up in such a way that the efficiency achieved for the sequential case can largely be maintained for a parallel implementation on loosely coupled parallel machine architectures.},
booktitle = {{PARLE} '91 {Parallel} {Architectures} and {Languages} {Europe}},
publisher = {Springer Berlin Heidelberg},
- author = {N\"{o}cker, E. G. J. M. H. and Smetsers, J. E. W. and {\noopsort{Eekelen}van Eekelen}, M. C. J. D. and Plasmeijer, M. J.},
+ author = {N\"{o}cker, E. G. J. M. H. and Smetsers, J. E. W. and \noopsort{Eekelen}{van Eekelen}, M. C. J. D. and Plasmeijer, M. J.},
editor = {Aarts, Emile H. L. and van Leeuwen, Jan and Rem, Martin},
year = {1991},
pages = {202--219},
abstract = {More and more applications rely on the safe execution of code unknown at compile-time, for example in the implementation of web browsers and plugin systems. Furthermore, these applications usually require some form of communication between the added code and its embedder, and hence a communication channel must be set up in which values are serialized and deserialized. This paper shows that in a functional programming language we can solve these two problems at once, if we realize that the execution of extra code is nothing more than the deserialization of a value which happens to be a function. To demonstrate this, we describe the implementation of a serialization library for the language Clean, which internally uses an interpreter to evaluate added code in a separate, sandboxed environment. Remarkable is that despite the conceptual asymmetry between "host" and "interpreter", lazy interworking must be implemented in a highly symmetric fashion, much akin to distributed systems. The library interworks on a low level with the native Clean program, but has been implemented without any changes to the native runtime system. It can therefore easily be ported to other programming languages.We can use the same technique in the context of the web, where we want to be able to share possibly lazy values between a server and a client. In this case the interpreter runs in WebAssembly in the browser and communicates seamlessly with the server, written in Clean. We use this in the iTasks web framework to handle communication and offload computations to the client to reduce stress on the server-side. Previously, this framework cross-compiled the Clean source code to JavaScript and used JSON for communication. The interpreter has a more predictable and better performance, and integration is much simpler because it interworks on a lower level with the web server.},
booktitle = {Proceedings of the 31st {Symposium} on {Implementation} and {Application} of {Functional} {Languages}},
publisher = {ACM},
- author = {Staps, Camil and {\noopsort{Groningen}van Groningen}, John and Plasmeijer, Rinus},
+ author = {Staps, Camil and \noopsort{Groningen}{van Groningen}, John and Plasmeijer, Rinus},
year = {2019},
note = {event-place: Singapore, Singapore},
keywords = {functional programming, interpreters, laziness, sandboxing, web-assembly},
abstract = {The interface with the outside world has always been one of the weakest points of functional languages. It is not easy to incorporate I/O without being allowed to do side-effects. Furthermore, functional languages allow redexes to be evaluated in any order while I/O generally has to be performed in a very specific order. In this paper we present a new solution for the I/O problem which we have incorporated in the language Concurrent Clean. Concurrent Clean offers a linear type system called Unique Types. It makes it possible to define functions with side-effects without violating the functional semantics. Now it is possible to change any object in the world in the way we wanted: e.g. arrays can be updated in-situ, arbitrary file manipulation is possible. We have used this powerful tool among others to create a library for window based I/O. Using an explicit environment passing scheme provides a high-level and elegant functional specification method for I/O, called Event I/O. Now the specification of I/O has become one of the strengths of functional languages: interactive programs written in Concurrent Clean are concise, easy to write and comprehend as well as efficient. The presented solution can in principle be applied for any other functional language as well provided that it actually uses graph rewriting semantics in the implementation.},
booktitle = {Functional {Programming}, {Glasgow} 1992},
publisher = {Springer London},
- author = {Achten, Peter and {\noopsort{Groningen}van Groningen}, John and Plasmeijer, Rinus},
+ author = {Achten, Peter and \noopsort{Groningen}{van Groningen}, John and Plasmeijer, Rinus},
editor = {Launchbury, John and Sansom, Patrick},
year = {1993},
pages = {1--17},
abstract = {Differences in features supported by the various contemporary commercial workflow management systems point to different insights of suitability and different levels of expressive power. The challenge, which we undertake in this paper, is to systematically address workflow requirements, from basic to complex. Many of the more complex requirements identified, recur quite frequently in the analysis phases of workflow projects, however their implementation is uncertain in current products. Requirements for workflow languages are indicated through workflow patterns. In this context, patterns address business requirements in an imperative workflow style expression, but are removed from specific workflow languages. The paper describes a number of workflow patterns addressing what we believe identify comprehensive workflow functionality. These patterns provide the basis for an in-depth comparison of a number of commercially availablework flow management systems. As such, this paper can be seen as the academic response to evaluations made by prestigious consulting companies. Typically, these evaluations hardly consider the workflow modeling language and routing capabilities, and focus more on the purely technical and commercial aspects.},
number = {1},
journal = {Distributed and Parallel Databases},
- author = {{\noopsort{Aalst}van der Aalst}, W.M.P. and {\noopsort{Hofstede}ter Hofstede}, A.H.M. and Kiepuszewski, B. and Barros, A.P.},
+ author = {\noopsort{Aalst}{van der Aalst}, W.M.P. and \noopsort{Hofstede}{ter Hofstede}, A.H.M. and Kiepuszewski, B. and Barros, A.P.},
month = jul,
year = {2003},
pages = {5--51},
repositories / phd-thesis.git / blobdiff