On Mar 18, 2007, at 10:06 AM, AndrevanTonder wrote:
On Fri, 9 Mar 2007, R. Kent Dybvig wrote:
The present description of libraries leaves open the possibility
that a
continuation grabbed within a variable definition's right-hand-side
expression and subsequently invoked might cause the
reinitialization, with
different values, of some or all of the local counterparts of the
exported
variables, effecting implicit assignments to variables that are
supposed
to immutable.....
Proposal:
Add new wording to the effect that the continuation of the right-
hand-side
expression of a library variable definition should not be returned
to more
than once and that implementations either "should" or "must" raise an
exception if this occurs.
Do you intend this to apply to all variable definitions or just to
those that are exported?
I think the restriction applies to all "immutable" bindings since all
of them
*are* exported (explicitly or implicitly).
If one is going to apply this also to unexported definitions,
The only unexported definitions are those that are assigned (via
set!) in the
body of the defining library. I don't think the restriction needs to
apply to
these guys (but could be wrong).
the question arises as to why one wouldn't apply it also to
internal definitions in lambda bodies.
Because these are ordinary mutable variables. Whenever you want
immutable
variables, you have to guard against any circumstance which could
modify the
value of the variable (including multiple return using call/cc).
Aziz,,,
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
