Date: Thu, 28 Jun 2012 17:55:54 -0400
   From: John Cowan <cowan@mercury.ccil.org>

   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
particular implementation.

 ... 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
binding.

   As the SRFI notes, this is currently done in various ways.

Which SRFI?

   > - 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.

                                       -Richard Kelsey

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports