many updates
[phd-thesis.git] / other.bib
index 19b806a..586d6be 100644 (file)
--- a/other.bib
+++ b/other.bib
@@ -1765,3 +1765,20 @@ Publisher: Association for Computing Machinery},
        keywords = {Energy, Environment, IoT, Smart city, SpliTech2020, Sustainability},
        pages = {122877},
 }
+
+@inproceedings{staps_lazy_2019,
+       address = {New York, NY, USA},
+       series = {{IFL} '19},
+       title = {Lazy {Interworking} of {Compiled} and {Interpreted} {Code} for {Sandboxing} and {Distributed} {Systems}},
+       isbn = {978-1-4503-7562-7},
+       url = {https://doi.org/10.1145/3412932.3412941},
+       doi = {10.1145/3412932.3412941},
+       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 = {Association for Computing Machinery},
+       author = {Staps, Camil and van Groningen, John and Plasmeijer, Rinus},
+       year = {2019},
+       note = {event-place: Singapore, Singapore},
+       keywords = {functional programming, interpreters, laziness, sandboxing, web-assembly},
+       file = {Staps et al. - 2019 - Lazy Interworking of Compiled and Interpreted Code.pdf:/home/mrl/.local/share/zotero/storage/LGS69CH8/Staps et al. - 2019 - Lazy Interworking of Compiled and Interpreted Code.pdf:application/pdf},
+}