A located lambda calculus

A located lambda calculus. Ezra Cooper and Philip Wadler. Submitted to ICFP 2008.

Several recent language designs have offered a unified language for programming a distributed system; we call these "location-aware" languages. These languages provide constructs that allow the programmer to control the location (the choice of host, for example) where a piece of code should run, which can be useful for security or performance reasons. On the other hand, a central mantra of web engineering insists that web servers should be "stateless": that no "session state" should be maintained on behalf of individual clients---that is, no state that pertains to the particular point of the interaction at which a client program resides. Thus far, most implementations of unified location-aware languages have ignored this precept, usually keeping a process for each client running on the server, or otherwise storing state information in memory. We show how to implement a location-aware language on top of the stateless-server model.

This paper is technical, and I assume most LtU members will mainly read sections 1, 5 & 6. Figure 5 is definition of the located LC.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Defunctionalisation

Do you have some links that explain defunctionalisation and how it is useful in a client-server programming setting?

If the explanation is more informal all the better ;-)

Defunctionalization at Work

Defunctionalization at Work Also check the citations and citations of it.

Basically, defunctionalization is one of a few approaches to turn higher-order data into first-order data. If we CPS transform and then defunctionalize, we get a concrete representation of the (control) stack. I haven't read the paper of this topic yet, but I suspect that the purpose of defunctionalization and CPS transforming here is to reify control and easily store and serialize (and thus distribute) it.

Lambda into values

Nice, thanks for the link. So if I understood right defunctionalisation transforms a lambda expression into a series of values: the function label (or constructor, used for discrimination) and the free variables. A common 'apply' function returns the appropriate result when it receives an expression built with a specific constructor.

I understand what you mean by "reify control and easily store and serialize it". That way lambda expressions can be used in client-server communication, provided the recipient holds the code corresponding to the constructor sent over the wire.

Well-timed - one of the two

Well-timed - one of the two big drawbacks I've been thinking about recently wrt continuation based servers was the lack of mobility/serialization of continuations, which does not jive well with the ajax / thick client world. Some of the PLT Server papers mentioned work in progress in this area, but I don't recall anything beyond the paper on enabling continuations on top of traditional stack architectures (concretely, the CLR).

Looking forward to the read, thanks :)

[Fixed]

Per request, I edited the story.

Three essential transformations

The redacted bits of the post were helpful, I think.

From the paper: "Our technique involves three essential transformations: defunctionalization, ... CPS transformation, and a 'trampoline' that allows tunnelling server-to-client requests within server responses."

Also: "In the future, we hope to extend ... by adding features such as exceptions and generalizing by allowing [the location annotations] to consist of a set of permissible locations. We also hope to implement the ... calculus with location brackets in the Links language."