simpson@usc.edu (Scott Simpson) (10/15/89)
I just finished the Eiffel book, and I found some bugs, made some comments
and had some questions. Here they are.
Eiffel book version "3 4 5 92 91 90 89 88"
Classifications: bug, comment, question
Negative line numbers denote lines from the bottom of the page.
p. 119, section 7.3.2, line 6 (bug)
The comment at the end of the full function should be "-- full"
not "-- empty".
p. 188, section 9.1.2, (bug) lines 27 to 28
The lines
previous.change_right(new);
new.change_right(previous.right);
should be transposed in the routine "insert".
p. 190, section 9.1.4, lines 12 to 13 (bug)
Search returns a zero value if an element is not found, not
nb_elements+1 as the sentence says.
p. 196, section 9.2.4, lines 9 to 11, -6 (bug)
Reserved words are not in boldface in the offright routine.
Also, on the same page, the "or" in the go function is not in boldface.
p. 271, section 11.4.6, line 19 (bug)
In the first sentence, change y := x to x := y
p. 282, section 12.1.1, line 11 (bug)
Need a comment delimiter before
end; setheight
p. 300, section 12.3.6, line -7 (bug)
In the second sentence, change "now" to "know".
p. 302, section 12.3.6 (bug)
The code
transition : ARRAY2[STATE]
should be changed to
transition : ARRAY2[INTEGER]
p. 313, section 13.3.7, lines 9 and 11 (bug)
f: A is do Result.Create end;
f: B is do Result.Create end;
Change boths "do"s to "once".
p. 315, section 13.4, line 26 (bug)
Change the sentence "...that a manifest constant cannot be passed as
actual argument..." to "...that a manifest constant cannot be passed as
an actual argument..."
p. 359, section 16.3, lines 21 to 22 (bug)
Change "Given two criteria and three possibilities for each, we are
in principle faced with nine possibilities." to "Given two criteria and
three possibilities for each, we are in principle faced with six
possibilities."
p. 381, section 17.4.2, line 24 (bug)
Change
x.C_rout(x, arg1, arg2, ..., argn)
to
C_rout(x, arg1, arg2, ..., argn)
p. 386, section 18.2, lines -7 to -10 (comment)
The statement (in reference to Ada)
The former term is too strong for a construct that does not
support any formal description of the package semantics (in
the form of assertions or similar mechanisms), so we shall
use the more modest word "interface".
This ignores the work of David Luckham's Anna annotation language for
Ada. Anna adds assertions much like Eiffel to Ada comments. The Anna
preprocessor generates Ada code to handle the assertions. Since the
assertions are in comments, the program can be compiled without running
your Ada program through Anna first but then you wouldn't get the
benefits of the assertions. Here is some example Anna:
--| where out (A (A'FIRST) = in A (A'LAST)),
--| out (A (A'LAST) = in A (A'FIRST)),
--| A (Index_Type'SUCC (A'FIRST) .. Index_Type'PRED (A'LAST)) =
--| in A (Index_Type'SUCC (A'FIRST) .. Index_Type'PRED (A'LAST));
Granted, having assertions in "comments" is not the cleanest mechanism,
but you may wish to acknowledge this work in your book.
p. 395, section 18.4.4, lines 17 to 20 (comment)
The statement (in the section on if-then-else's vs. exceptions)
The second aspect of provides an argument in support of
the classical form: if a routine contains more than one call
to pop, the way to deal with empty stacks will almost certainly
be different depending on the context of each of these calls.
This may be true, but Ada allows exception handlers to be attached to
begin-end blocks. E.g.,
begin
pop(s);
exception
when underflow => action1;
end;
...
begin
pop(s);
exception
when underflow => action2;
end;
p. 396, section 18.4.4, lines 21 to 23 (bug)
The statement
The second possibility, retrying, may only be implemented in
Ada by gotos, since there is no equivalent to the retry
instruction of Eiffel.
This is not allowed. From the Ada Reference Manual section 5.9(5)
The above rules allow transfer of control to a statement of an
enclosing sequence of statements but not the reverse. Similarly,
they prohibit transfers of control such as between alternatives
of a case statement, if statement, or select statements; between
exception handlers; or from an exception handler of a frame back to
the sequence of statements of this frame.
p. 408, section 19.2, figure 19.1 (bug)
Change the underscore in the DIRECTORY bubble to a hyphen.
p. 412, section 19.4.2, line -4 (bug)
Change
change_value(new : T) is
to
change_value(new : INTEGER) is
p. 441, section 20.3.1, lines 10 to 13 (comment)
The paragraph discussing friend functions implies that their sole purpose
is to interface with C code; rather, they are used as an information hiding
mechanism.
p. 452, section A.1, line 18 (bug)
Change
if minb >= maxb then
to
if minb <= maxb then
Also, why doesn't this routine take into account the size of the formal
generic parameter T? How does this routine raise the exception
storage_error?
p. 456, section A.2, line 1 (bug)
The header line lists section A.4 when it is still in section A.2.
p. 456, section A.2, lines 3 to 16 (question)
Why are the routines "start" and "forth" deferred when they can use "go" like
"finish" does?
p. 457, section A.2, line -3 (question)
How is the entity no_change_since_mark used? Should it be initialized to
false?
p. 461, section A.4, line 19 (bug)
Change the comment
-- (for use in connection with [T] and TWO_WAY_LIST[T])
to
-- (for use in connection with LINKED_LIST[T] and TWO_WAY_LIST[T])
p. 478, section B.2, line 10
Change
do Result := (balance >= minimum_balance) end; -- deposit
to
do Result := (balance - sum >= minimum_balance) end; -- deposit
p. 484, section B.7, line -13
Change
if c then p := r end;
to
if c then h := r end;
Scott Simpson
TRW Space and Defense Sector
usc!trwarcadia!simpson (UUCP)
trwarcadia!simpson@usc.edu (Internet)