Re: Issue: DEFPACKAGE (version 6)

[masinter.pa@Xerox.COM]

Arguments of the form "we should leave A undefined because B is undefined"
are weak, especially if there is some hope of defining B.

However, I don't think we will make much progress on DEFPACKAGE unless we
leave, for now, that the results of executing more than one DEFPACKAGE on
the same string is unspecified. We might want to add to the commentary that
we expect some implementations may signal a continuable error, but other
environment-specific action might also be reasonable.


Now that we have the new error terminology, I think encoruaging the
signalling of an error might be a reasonable resolution if we expect
legitimate programs to actually catch the error and process it. One
criteria by which we should judge that might be how far we are willing to
specify the exact nature of the condition to be signalled.

In this case, we're not close to a good design that is agreeable.

Could we get a new writeup with the "redefinition" behavior explicitly
vague?