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                        cowan@ccil.org
    Using XSLT
On an XML DBMS.

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