Andrew C. Greenberg
werdna at mucow.com
Tue Dec 17 12:14:52 UTC 2002
Indeed, Richard's reparse (rewrite) makes far more sense than the
standard language. His clarification should be forwarded to the powers
By way of explanation how such things can happen, let us remember the
fourth law of thermodynamics -- that the number of nontrivial programs
that are bug-free is zero. An analogous principle is that the number
of nontrivial specifications that are bug-free (in the abstract
truth-seeking sense -- they cannot have "bugs," strictly speaking since
they specify the result) is likewise zero -- these specifications are
not final because they are infallible, they are infallible because they
are final. Since the spec has not been used as a sole guide for many
new Smalltalk implementations, it is unsurprising that "spec-bugs"
exist and will remain for awhile -- there isn't a syntax compiler or
test suite that facilitates finding bugs in these documents, only
code-readings such as that of Richard will do that.
No specification has been immune from these problems -- some are more
at risk than others.
This is the reason why the ANSI standard is not a gospel -- and that
mere word-lawyering from that document probably should not inform
beyond technical suggestion any dramatic changes in Squeak and standard
On Monday, December 16, 2002, at 10:00 PM, Richard A. O'Keefe wrote:
> I've now got a copy of the published version of the ANSI Smalltalk
> standard. Has too much study driven me mad, or is the following
> method description seriously broken?
> 18.104.22.168 Message: raisedToInteger: operand
> Answer the receiver raised to the power operand.
> Definition: <number>
> Answer the receiver raised to the power operand,
> which must be a whole number.
> If the operand is a whole number greater than or equal to zero,
> then the result is the receiver raised to the power operand.
>>>> If operand is a negative whole number, then the result is
>>>> equivalent to the reciprocal of the absolute value of the
>>>> receiver raised to the power operand.
> The highlighted sentence is ambiguous.
> Suppose we have (p raisedToInteger: q) where p is a positive
> integer and q is a negative integer.
> Reading 1:
> The result is ... the reciprocal of ((the absolute value of
> the receiver) raised to the power operand).
> ^((self abs) raisedToInteger: operand) reciprocal
> Reading 2:
> The result is ... (the reciprocal of (the absolute value of
> the receiver)) raised to the power operand.
> ^(self abs reciprocal) raisedToInteger: operand
> Surely it should be
> The result is ... (the reciprocal of the receiver) raised to
> the power (the absolute value of operand).
> ^self reciprocal raisedTo: operand abs
> or else
> The result is ... the reciprocal of (the receiver raised to
> the power (the absolute value of operand)).
> ^(self raisedTo: operand abs) reciprocal
> There are other glitches I laughed at in the 1.9 draft, but
> they don't seem quite as funny when I've paid for the final version
> and they are still there.
More information about the Squeak-dev