[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

storing into a literal



> 3.4 Storage model  (page 7, column 1-2)
> ------------------------------
> 
>   ``In many systems it is desirable for constants ... it is an error
>   to attempt to store a new value into a location that is denoted by
>   an immutable object.''
> 
> This paragraph seems to be weaker than intended.  I read it as:
> 
>   * Some implementations flag data from literals as immutable
>   * It is an error to store into an immutable object.
>   * Therefore, in some implementations it is an error to store into a
>     literal.

I apologize for the unclear wording of this paragraph, and I hope
that it gets cleaned up in R6RS.

The intended meaning is:

    1.  Rationale: In many systems...
    2.  How we're going to specify this:  To express this,
        it is convenient to imagine...
    3.  Definition that applies to all implementations:
        The constants and the strings returned by SYMBOL->STRING
        are then the immutable objects, while all objects created
        by the other procedures listed in this report are mutable.
    4.  Definition that applies to all implementations:
        It is an error to store into an immutable object.

Hence it is always an error to store into the value of a literal.
Few existing implementations are capable of detecting this error,
but it is always an error.

In the R*RS, an error always implies implementation-dependent
behavior.  For political reasons, errors that implementations
cannot reasonably be expected to detect are sometimes described
by euphemisms such as "behavior is implementation-dependent"
instead of "error", but that isn't what happened here.

Will