2006 Scheme and Functional Programming Papers, University of

· ; · ; · :: Store × Frame Stack × Expression −→ Store × Frame Stack × Expression
µ ; Φ ; E[((λ (x 1 . . . x n) e) v 1 . . . v n)] −→ µ ; Φ ; E[e[x 1/v 1, . . . , x n/v n]]
µ ; Φ ; E[(call/cc e)] −→ µ ; Φ ; E[(e (λ (x) (abort Φ E[x])))]
µ ; Φ ; E[(abort Φ ′ e)] −→ µ ; Φ ′ ; e
µ ; Φ ; E[(push-frame!)] −→ µ ; (∅, Φ) ; E[(λ (x) x)]
µ ; (φ, Φ) ; E[(make-cell v)] −→ µ[l ↦→ v] ; (φ[n ↦→ l], Φ) ; E[(cell n)]
where n and l are fresh
µ ; Φ ; E[(cell-ref (cell n))] −→ µ ; Φ ; E[l(µ, Φ, n)]
µ ; (φ, Φ) ; E[(cell-shadow (cell n) v)] −→ µ[l ↦→ v] ; (φ[n ↦→ l], Φ) ; E[(cell n)]
where l is fresh
Figure 11. The reduction steps of λ F S
v ::= (λ (x . . . ) e)
(abstractions)
| c
c ::= (cell n)
(cells)
where n is an integer
e ::= v (values)
| x (identifiers)
| (e e . . . ) (applications)
| (call/cc e) (continuation captures)
| (abort Φ e) (program abortion)
where Φ is a frame stack (Fig. 9)
| (push-frame!) (frame creation)
| (make-cell e) (cell creation)
| (cell-ref e e) (cell reference)
| (cell-shadow e e) (cell shadowing)
Stores
µ :: Store
µ ::= ∅ (empty store)
| µ[l ↦→ v] (location binding)
Frames
φ :: Frame
φ ::= ∅ (empty frame)
| φ[x ↦→ l] (cell identifier binding)
Frame Stack
Φ :: Frame Stack
Φ ::= ∅ (empty frame stack)
| φ, Φ (frame entry)
Figure 9. The semantic domains of λ F S
Figure 8. Syntax of λ F S
is created, it is placed in the store with its parent as the old frame
stack top.
The semantics is relatively simple. The cell and frame operations
are quite transparent. We have included call/cc/frame (in
Fig. 10) as an abbreviation, rather than a reduction step, to keep the
semantics uncluttered. If we were to encode it as a reduction step,
that step would be:
µ ; Φ ; E[(call/cc/frame e)] −→
µ ; Φ ; E[e (λ (x) (abort Φ E[(seqn (push-frame!) x)]))]
The order of frame creation in call/cc/frame is important. The
implementation must ensure that each invocation of a continuation
has a unique frame, and therefore a Refresh does not share the same
frame as the initial request. The following faulty reduction step fails
to ensure that each invocation has a unique frame:
µ ; Φ ; E[(call/cc/frame e)] −→
µ ; Φ ; E[e (λ (x) (abort (, Φ) E[x]))]
where is a frame constructed at capture time.
In this erroneous reduction, the new frame is created when the
continuation is created, rather than each time it is invoked. Observe
that the correct reduction preserves the invariant that each frame has
a unique incoming edge in the interaction tree, which this reduction
violates.
6. Applications
Web cells answer a pressing need of stateful Web components: they
enable (a) defining stateful objects that (b) behave safely in the face
of Web interactions while (c) not demanding a strong invariant of
global program structure. Other techniques fail one or more of these
criteria: most traditional scoping mechanisms fail (b) (as we have
discussed in Sec. 4), while store-passing clearly violates (c).
Before we created Web cells, numerous PLT Scheme Web server
applications—including ones written by the present authors—used
to employ fluid-let; based on the analysis described in this paper,
we have been able to demonstrate genuine errors in these applications.
As a result, PLT Scheme Web server users have adopted Web
cells in numerous applications, e.g., a server for managing faculty
job applications, a homework turn-in application, a BibTeX frontend,
a personal weblog manager, and, of course, CONTINUE itself.
We present three more uses of Web cells below.
142 Scheme and Functional Programming, 2006