Dynamic binding, ballot (with better line breaks)

[Richard P. Gabriel <rpg@lucid.com>]

|--------|-------------------------------------------------------------------|
|        |                                                                   |
|        | I do not object to including a description of dynamic binding, as |
|        | defined in the recent message to RRRS-Authors, in an appendix to  |
|        | R4RS.                                                             |
|        |                                                                   |
|--------|-------------------------------------------------------------------|
|        |                                                                   |
|        | I do not object to including a description of dynamic binding,    |
|        | similar to that in the recent message to RRRS-Authors, in an      |
|        | appendix to R4RS as long as it reflects the changes I want.       |
|        | A brief overview of my desired changes appears below this ballot. |
|        |                                                                   |
|--------|-------------------------------------------------------------------|
| X   X  |                                                                   |
|  X X   | I object to including a description of dynamic binding, similar   |
|   X    | to that in the recent message to RRRS-Authors, in an appendix to  |
|  X X   | R4RS.                                                             |
| X   X  |                                                                   |
|--------|-------------------------------------------------------------------|


Additional comments:

There are several things I find wrong about this proposal. The first is the
reason I object to inclusion, and the rest are probably repairable. 

1. This is a real assembly-language view of binding. This is exactly
what I would have expected in some sort of virtual machine description
of Scheme.  This is not what I would call a clean integration of
dynamic binding with Scheme. (If you think it is, try writing
factorial using the primitives you get by substiting ``lexical'' for
``dynamic'' in the proposal.)

Though Scheme has always seemed to be a low-level language to me, this
is really taking it to an extreme in a wrong direction.  I'd rather
tell people to figure out how to program without dynamic variables
than provide language features like these.

The next three things I find wrong with the proposal has to do with
dropping the concept of variable from the presentation.

2. The names MAKE-DYNAMIC, DYNAMIC?, DYNAMIC-REF, and DYNAMIC-SET!
refer to procedures that have nothing to do with dynamic anything.  If
I MAKE-DYNAMIC, what is dynamic about the thing I get back?  What is
dynamic about it is that it is an object that forms part of an
implementation of a dynamic environment. Without a careful description
of dynamic environments, these names are stupid (and they might be
stupid anyway).

3. In this description of DYNAMIC-REF it is not clear what a
dynamic environment is:

``(DYNAMIC-REF dyn)                                      [Procedure]

Return the value of the given dynamic in the current dynamic environment.''

4. Reading up to here in the proposal doesn't prepare me for reading
about binding dynamics to new locations, which is mentioned in the
description of CALL-WITH-DYNAMIC-BINDING:

``(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.''

What does it mean to ``bind a dynamic to a new location''?  At this
point it is as sensible as saying ``bind a vector to a new location.''
What is a nested environment?

Well, it would all make sense if the concept of variable weren't swept
under the rug.

5. I've been given enough silly putty to construct a dynamic environment,
but I cannot construct several to be used at the same time.

6. I shudder when I try to imagine the sort of program that would
actually use DYNAMIC?. I suppose it makes implementation easier to
introduce this new type, but what an awful thing. Why not use symbols
for this? These symbols are already distinguished by being in the
dynamic environment.

Here is the start of a rewrite that leverages the current concepts of
variable, binding, environment, and location (By the way, I find
objectionable the use of locations to describe binding and variables,
plus it isn't necessary. On the other hand, it is harmonious with the
assembly-language-like nature of dynamics.):

A dynamic environment is an environment in which objects called
dynamics behave like variables: a dynamic names a location in a
dynamic environment where a value can be stored. Dynamic environments
can be (dynamically) nested. The value of a given dynamic is given by
the (dynamically) innermost dynamic environment with a binding for
that dynamic. At any point there is a current dynamic environment.
The outermost dynamic environment is called the global dynamic
environment.

(MAKE-DYNAMIC obj)                                     [Procedure]

Create and return a new ``dynamic'' whose value in the global dynamic
environment 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 is nested within the dynamic environment of the invocatio	n of
CALL-WITH-DYNAMIC-BINDING.  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.

....

			-rpg-