Richard Kelsey scripsit: > Summary: The descriptions of the dynamic features need to be clearer > and more consistent.
Formal Comment ticket #426 filed. I'd like a little clarification (and assistance) here. > 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"? > - 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. As the SRFI notes, this is currently done in various ways. The WG decided to forbid the "reinitialize in new thread" approach and make the difference between "copy into new thread" and "share between new and old threads" moot by making parameter assignment (as opposed to rebinding) not part of the spec. > - The description of raise talks about the dynamic extent of > continuations, but it is calls that have a dynamic extent, not > continuations. Rephrase it in terms of continuations and dynamic > environments. New text would be very helpful here. > - The description of raise-continuable also needs to be rephrased in > terms of continuations and dynamic environments. Ditto here. > - 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. -- My corporate data's a mess! John Cowan It's all semi-structured, no less. http://www.ccil.org/~cowan But I'll be carefree [email protected] Using XSLT On an XML DBMS. _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
