commit e8d23565df7fd8417333c425f46a22f821b27f21
parent 07b17b0ad78faab1ef3e147c9f9072350fae2a57
Author: Wolfgang Corcoran-Mathe <wcm@sigwinch.xyz>
Date: Tue, 30 Jan 2024 15:53:51 -0500
3.4: Reflow.
Diffstat:
1 file changed, 40 insertions(+), 35 deletions(-)
diff --git a/doc/r7rs-small/r7rs-small.texinfo b/doc/r7rs-small/r7rs-small.texinfo
@@ -976,41 +976,46 @@ in the appropriate sections of chapter 6.
@node Storage model
@section Storage model
-Variables and objects such as pairs, strings, vectors, and bytevectors implicitly denote
-locations or sequences of locations. A string, for example, denotes as many locations as
-there are characters in the string. A new value can be stored into one of these locations
-using the @code{string-set!} procedure, but the string continues to denote the same locations as
-before.
-
-An object fetched from a location, by a variable reference or by a procedure such as @code{car},
-@code{vector-ref}, or @code{string-ref}, is equivalent in the sense of @code{eqv?} (@ref{Equivalence predicates}) to the object last
-stored in the location before the fetch.
-
-Every location is marked to show whether it is in use. No variable or object ever refers to a
-location that is not in use.
-
-Whenever this report speaks of storage being newly allocated for a variable or object,
-what is meant is that an appropriate number of locations are chosen from the set of
-locations that are not in use, and the chosen locations are marked to indicate that they
-are now in use before the variable or object is made to denote them. Notwithstanding
-this, it is understood that the empty list cannot be newly allocated, because it is a unique
-object. It is also understood that empty strings, empty vectors, and empty bytevectors,
-which contain no locations, may or may not be newly allocated.
-
-Every object that denotes locations is either mutable or immutable. Literal constants, the
-strings returned by @code{symbol->string}, and possibly the environment returned by
-@code{scheme-report-environment} are immutable objects. All objects created by the other
-procedures listed in this report are mutable. It is an error to attempt to store a new value
-into a location that is denoted by an immutable object.
-
-These locations are to be understood as conceptual, not physical. Hence, they do not
-necessarily correspond to memory addresses, and even if they do, the memory address
-might not be constant.
-
-Rationale: In many systems it is desirable for constants(i.e. the values of literal
-expressions) to reside in read-only memory. Making it an error to alter constants
-permits this implementation strategy, while not requiring other systems to
-distinguish between mutable and immutable objects.
+Variables and objects such as pairs, strings, vectors, and bytevectors
+implicitly denote locations or sequences of locations. A string, for
+example, denotes as many locations as there are characters in the string. A
+new value can be stored into one of these locations using the
+@code{string-set!} procedure, but the string continues to denote the same
+locations as before.
+
+An object fetched from a location, by a variable reference or by a procedure
+such as @code{car}, @code{vector-ref}, or @code{string-ref}, is equivalent
+in the sense of @code{eqv?} (@ref{Equivalence predicates}) to the object
+last stored in the location before the fetch.
+
+Every location is marked to show whether it is in use. No variable or object
+ever refers to a location that is not in use.
+
+Whenever this report speaks of storage being newly allocated for a variable
+or object, what is meant is that an appropriate number of locations are
+chosen from the set of locations that are not in use, and the chosen
+locations are marked to indicate that they are now in use before the
+variable or object is made to denote them. Notwithstanding this, it is
+understood that the empty list cannot be newly allocated, because it is a
+unique object. It is also understood that empty strings, empty vectors, and
+empty bytevectors, which contain no locations, may or may not be newly
+allocated.
+
+Every object that denotes locations is either mutable or immutable. Literal
+constants, the strings returned by @code{symbol->string}, and possibly the
+environment returned by @code{scheme-report-environment} are immutable
+objects. All objects created by the other procedures listed in this report
+are mutable. It is an error to attempt to store a new value into a location
+that is denoted by an immutable object.
+
+These locations are to be understood as conceptual, not physical. Hence,
+they do not necessarily correspond to memory addresses, and even if they do,
+the memory address might not be constant.
+
+Rationale: In many systems it is desirable for constants(i.e. the values of
+literal expressions) to reside in read-only memory. Making it an error to
+alter constants permits this implementation strategy, while not requiring
+other systems to distinguish between mutable and immutable objects.
@node Proper tail recursion
@section Proper tail recursion
