[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Pavel's Comments
``Page 1-4, second set of bullets, second bullet -- Can't valid programs
rely on that error being signalled if they also specify (SAFETY 3)? I'm
generally unhappy with the phrase "at least in code compiled under one
compiler safety optimization level". I'd prefer a direct statement that
that level is 3.''
I don't to make CLOS depend on things that might change in Common Lisp
if I don't have to. Why state ``3'' when ``at least one'' will do?
``Page 1-5, third bullet -- What does the clause "but they must remain
undefined" mean? Does that mean that my implementation is incorrect if
I document just which nasty bug will crop up if situation S occurs? I
can't derive any useful content from this clause.''
As I mentioned in my message of July 8 containing the original proposal
which was accepted, this is to prevent implementations from using
the ``is an error'' out from Common Lisp. In Common Lisp, ``it is an
error'' means that no valid Common Lisp program should cause this situation
to occur and that the results are ``completely undefined.'' Steele goes on
to say that ``some particular implementation might ... define the effects and
results for such a situation.'' Steele mentions that ``must not'' means
``is an error.''
I have heard people argue as follows:
``It is an error to adjust an array that was not created with the
:adjustable argument non-nil. Therefore the results are undefined.
Therefore an implementation can define the behavior. Therefore, it is
ok to adjust an array created with the :adjustable argument nil.''
I want to prevent this. It's ok for your implementation to document that
the results are harmless, but I would prefer that you not state what they
are.
The other comments look good and duplicate a lot of Moon's comments, virtually
all of which are being incorporated. I expect the same will be true here.
Thanks, Pavel.
-rpg-