[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Formal Comment: clarify the semantics of the dynamic features
Date: Thu, 28 Jun 2012 17:55:54 -0400
From: John Cowan <cowan@x>
Richard Kelsey scripsit:
> For example, dynamic bindings are described using the term 'dynamic
> environment' which is itself not defined. There is a paragraph on
> how dynamic bindings interact with threads, which are not mentioned
> anywhere else in the report, but nothing is said about how dynamic
> bindings interact with call/cc or dynamic-wind.
The intention is that dynamic bindings are implemented either directly
by dynamic-wind, or using the same underlying mechanisms. Perhaps the
report should say "as if by dynamic-wind"?
The report should describe the semantics of dynamic variables, not one
... The param and value expressions are evaluated in an unspecified
order. The body is then evaluated and the results of the last
expression in the body are returned as the results of the entire
parameterize expression. Within the dynamic extent of the body, each
parameter returns the corresponding value, modified by the
parameter's conversion procedure, if any. If a parameter is called
within the dynamic extent of multiple parameterize expressions, it
returns the value from the most recent of those expressions in which
it occurs as a param.
> - Add a new section 3.6 that includes the definition of 'dynamic
> extent' currently in section 6.10 and a definition of 'dynamic
> environment'. Mention that the dynamic environment is captured by
> call/cc. Say something about threads, if necessary.
Mentioning threads is essential, because the whole reason that you can't
provide parameters yourself in portable code is that they have to interact
consistently with non-portable thread packages.
I don't see how the R7RS dynamic variables would work with any thread
package at all, portable or non-portable, that preserves the semantics
of dynamic-wind. You can't unwind and wind on context switch, so if
you have threads you can't use dynamic-wind or any other shallow-binding
mechanism to implement dynamic variables. I think you have to use deep
As the SRFI notes, this is currently done in various ways.
> - Ideally, the dynamic environment and dynamic-wind would be included
> in the formal semantics.
If anyone has a proposal here, it might be a Good Thing, but I wouldn't
know the difference between up and Tuesday when it comes to the formal
semantics, so I must decline either to write it or to edit it.
Editorial tickets #427 and #428 created. Ballot ticket #429 for new
formal semantics created. If nobody steps up to do this and review it
before the last ballot, it will be closed.
If the WG makes changes to the language that require changes to the
formal semantics, then they need to change the formal semantics. That
seems like part of the job.
Scheme-reports mailing list