Commit e1d42da0 authored by Paul Eggert's avatar Paul Eggert

Fix mutability glitches reported by Drew Adams

See Bug#40693#32.
* doc/lispref/eval.texi (Self-Evaluating Forms, Backquote):
Say that these yield constant conses, vectors and strings,
not constant symbols.
* doc/lispref/objects.texi (Constants and Mutability): Say that an
attempt to modify a constant variable signals an error, instead of
saying that it has undefined behavior.
parent 5805df74
Pipeline #5322 passed with stage
in 58 minutes and 1 second
......@@ -158,8 +158,8 @@ contents unchanged.
@end group
@end example
A self-evaluating form yields a constant, and you should not attempt
to modify the constant's contents via @code{setcar}, @code{aset} or
A self-evaluating form yields constant conses, vectors and strings, and you
should not attempt to modify their contents via @code{setcar}, @code{aset} or
similar primitives. The Lisp interpreter might unify the constants
yielded by your program's self-evaluating forms, so that these
constants might share structure. @xref{Constants and Mutability}.
......@@ -704,8 +704,8 @@ Here are some examples:
@end example
If a subexpression of a backquote construct has no substitutions or
splices, it acts like @code{quote} in that it yields a constant that
should not be modified.
splices, it acts like @code{quote} in that it yields constant conses,
vectors and strings that should not be modified.
@node Eval
@section Eval
......
......@@ -2395,17 +2395,19 @@ somewhere else.
Although numbers are always constants and markers are always
mutable, some types contain both constant and mutable members. These
types include conses, vectors, and strings. For example, the string
types include conses, vectors, strings, and symbols. For example, the string
literal @code{"aaa"} yields a constant string, whereas the function
call @code{(make-string 3 ?a)} yields a mutable string that can be
changed via later calls to @code{aset}.
A program should not attempt to modify a constant because the
Modifying a constant symbol signals an error (@pxref{Constant Variables}).
A program should not attempt to modify other types of constants because the
resulting behavior is undefined: the Lisp interpreter might or might
not detect the error, and if it does not detect the error the
interpreter can behave unpredictably thereafter. Another way to put
this is that mutable objects are safe to change, whereas constants are
not safely mutable: if you try to change a constant your program might
this is that although mutable objects are safe to change and constant
symbols reliably reject attempts to change them, other constants are
not safely mutable: if you try to change one your program might
behave as you expect but it might crash or worse. This problem occurs
with types that have both constant and mutable members, and that have
mutators like @code{setcar} and @code{aset} that are valid on mutable
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment