Re: bindings and assignments

["Perry E. Metzger" <address@hidden>]

Michael Sperber <sperber@informatik.uni-tuebingen.de> writes:
> The right kind of diagrams help greatly.

I would agree -- diagrams and examples probably help a lot.

> I think this is one of the instances where your knowledge of how the
> implementation hurts trying to backtrack to the underlying
> principles.

For bindings vs. assignment, I would say it might indeed hurt to know
too much detail of the implementation. Interestingly, for first class
continuations, I'd say I didn't have anything like a good handle on it
until I understood the implementations well. Then it becomes obvious
that what you are preserving is not the entirety of the program state
(including all the values in the environment) but instead just the
point in the control stack.

As long as I'm digressing...

R5RS has the following as nearly the entirety of its definition of a
continuation in the explanation of call-with-current-continuation,
which I must say is woefully inadequate:

    Whenever a Scheme expression is evaluated there is a continuation
    wanting the result of the expression. The continuation represents an
    entire (default) future for the computation.

For friends who know C well, I can explain that that call/cc is very
much like setjmp/longjmp except that one can longjmp back to a routine
that has exited without harm. I am not entirely clear on how I could
explain call/cc to someone without that background, though. The
examples in R5RS are particularly bad in that they don't show off what
might happen to bindings that were mutated in the lexical environment
of the function calling call/cc after the escape procedure was
captured but before it was invoked. In any case, part of this may be
that the definitions given for "continuation" and "first class
continuation" are often quite vague -- I've yet to see them crisply
described.



-- 
Perry E. Metzger		perry@piermont.com