[r6rs-discuss] [Formal] eliminate library export immutability loophole

From: Abdulaziz Ghuloum <aghuloum>
Date: Sun Mar 18 19:17:14 2007

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,,,
Received on Sun Mar 18 2007 - 19:17:01 UTC