[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
- References:
- r5 comments
- From: erik hilsdale <ehilsdal@cs.indiana.edu>