[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
dynamic binding proprosal
Here is the most recent version of the proposal for dynamic binding
that I could find. There was some discussion following this message.
-Norman
----------------------------------------------------------------
Date: Tue, 05 Dec 89 19:55:11 PST
From: Pavel.pa@Xerox.COM
To: RRRS-Authors
Cc: Pavel.pa@Xerox.COM
Subject: Dynamic binding, description for ballot
Here is the BASH proposal for dynamic binding again with a slight bit of
rewriting to avoid saying that the objects being manipulated here are
``dynamic variables'' since some folks dislike the notion that a
computation can return a ``variable'' of any kind. I have changed the name
to simply ``dynamic''.
I have also added the predicate DYNAMIC? which is true only of dynamics and
specified that dynamics are disjoint from all other Scheme types.
A separate message contains a ballot on the possible inclusion of a
description of dynamic binding in an appendix to R4RS.
Pavel
===========
We propose adding five procedures and one derived expression type to
Scheme:
(MAKE-DYNAMIC obj) [Procedure]
Create and return a new ``dynamic'' whose global value is obj.
(DYNAMIC? obj) [Procedure]
Return true if and only if obj is a dynamic. No object satisfying DYNAMIC?
satisfies any of the other standard type predicates.
(DYNAMIC-REF dyn) [Procedure]
Return the value of the given dynamic in the current dynamic environment.
(DYNAMIC-SET! dyn obj) [Procedure]
Change the value of the given dynamic to obj in the current dynamic
environment. The returned value is unspecified.
(CALL-WITH-DYNAMIC-BINDING dyn obj thunk) [Procedure]
Invoke and return the value of the given thunk in a new, nested dynamic
environment in which the given dynamic has been bound to a new location
whose initial contents are the value obj. This dynamic environment has
precisely the same extent as the invocation of the thunk and is thus
captured by continuations created within that invocation and re-established
by those continuations when they are invoked.
(DYNAMIC-BIND ((var-expr val-expr) ...) . body) [Syntax]
Evaluates the var-exprs and val-exprs in an unspecified order; the
var-exprs should yield dynamics. Returns the result of evaluating the body
in a new, nested dynamic environment in which the given dynamics have new
bindings, initialized to the given values. This dynamic environment has
precisely the same extent as the evaluation of the body and is thus
captured by continuations created within the body and re-established by
those continuations on invocation.
The DYNAMIC-BIND derived expression type has the following rewrite rule:
(dynamic-bind ((<var-expr1> <val-expr1>)
(<var-expr2> <val-expr2>)
...
(<var-exprN> <val-exprN>))
. <body>)
is equivalent to
(let ((var1 <var-expr1>)
(val1 <val-expr1>)
(var2 <var-expr2>)
(val2 <val-expr2>)
...
(varN <var-exprN>)
(valN <val-exprN>)
(body-thunk (lambda () . <body>)))
(call-with-dynamic-binding var1 val1
(lambda ()
(call-with-dynamic-binding var2 val2
(lambda ()
...
(call-with-dynamic-binding varN valN
body-thunk) ... )))))
===========
Notes:
-- Given ``dynamic-wind'', a portable shallow-binding implementation of the
proposal can be written for all single-processor implementations of Scheme.
It was suggested at the BASH meeting that something like this be done and
placed in the library. As stated in earlier messages, multiprocessor
implementations will have to implement it more primitively; Jinx has
pointed out, however, that two simple procedures for accessing the
process-specific dynamic environment suffice.
-- This proposal does not specify whether or not
``call-with-dynamic-binding'' tail-calls the given thunk. I think this is
proper. It is possible for deep-binding implementations to use tail-call,
but only at the expense of passing the dynamic environment on every
procedure call. In shallow binding implementations, it is probably not
possible at all.
===========
My intent was that the following sentence in the description of
CALL-WITH-DYNAMIC-BINDING described (informally) how the dynamic
environment interacts with call/cc:
``This dynamic has precisely the same extent as the invocation of the thunk
and is thus captured by continuations created within that invocation and
re-established by those continuations when they are invoked.''
I could write down the intent by modifying the formal semantics at the end
of the report (to pass around the dynamic environment), but that's seems a
bit heavy weight for such a forum. Alternatively, I could write some
examples showing how it works. The idea is simply that call/cc captures
the current dynamic environment in the procedure it creates and that
procedure re-establishes that environment when invoked.
Is this intent unclear to anyone on this list, or are we discussing how it
should be described in a report?