Copenhagen Programming Language Seminar
Generally speaking, servers and clients in Erlang are implemented as
named procedures in named modules. Similarly, processes communicate
via messages that have a statically-known structure, and specifically,
with static tags, that serve as the "names" of the messages. This
exposes and fixes a great deal of information about an Erlang
application: The names of the modules, the name of the entry-point
procedures within the module, the "names" of the messages between the
server and the client, etc.
This work explores how to gain anonymity through the use of anonymous
To spawn a process on a node, one must either to use a module name and
a function, or to pass an anonymous procedure. In order to use a
function from a module, the module file must be available on the
For a server to receive arbitrarily-many messages, the spawned
function must be recursive. Recursive functions are typically
implemented in Erlang via a name that is global to an Erlang module.
Running such a server requires that the client be aware of the name of
the module, the name of a function that serves as an entry point in
the module, and the arguments to that procedure.
Functional programming languages, especially of the dynamically-typed
variety (such as LISP, Scheme, Erlang), permit recursion to be
replaced with self-application, which means closures that are applied
to themselves. This is a classical technique that is based on
fixed-point theory in the lambda-calculus, which is the theoretical
foundation of all functional programming languages. It is a common
exercise in functional programming courses to implement recursive
functions using self-application instead of recursion, though in most
languages this amounts to a theoretical exercise. In Erlang, however,
replacing recursion with self-application can add flexibility,
anonymity and security. Specifically, we demonstrate how to
* spawn a fully-functional server without any particular module
located on the server node.
* run servers on any node, without requiring shared modules or access
to the file system.
* have client-server groups that can communicate via messages that
have randomly-selected names that change after each message. This
encapsulates communication, and makes it more secure, in a way similar
to how processes in the pi-calculus can communicate via
Andrzej Filinski Administrative host:Renée Korver Michan.
All are welcome.
The Copenhagen Programming Language Seminar (COPLAS) is a collaboration between DIKU, ITU and RUC.
COPLAS is sponsored by the FIRST Graduate School.
To receive information about COPLAS talks by email, send a message to firstname.lastname@example.org with the word 'subscribe' as subject or in the body.
For more information about COPLAS, see http://www.coplas.org