[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: DEFPACKAGE (Version 7)
- To: barmar@Think.COM
- Subject: Issue: DEFPACKAGE (Version 7)
- From: Jon L White <email@example.com>
- Date: Wed, 14 Dec 88 01:42:24 PST
- Cc: CL-CLEANUP@sail.stanford.edu
- In-reply-to: barmar@Think.COM's message of Sat, 10 Dec 88 15:57:29 EST <8812102057.AA18056@kulla.think.com>
re: . . . How about this as an
alternative to "at most the original package will be updated":
"however, no objects other than the original package will be
modified as a result."
Doesn't work -- by performing the newer definition, you may require links
to be modified in other packages' used-by lists.
If this really is an insoluable problem for you, and if other people
also feel so uncomfortable with it, then maybe we should just flush
the whole phrase; after all, the primary things we want to say are that:
(1) you don't change the name-to-package mapping, and
(2) you *might* alter the existing package [then again, you might not].
re: . . . Kathy's proposal for
the new classification system of error situations includes a
description of this case. As I said, I don't remember the actual
terminology she used for this case (I suggested "undefined but
benign", but she rejected it), but the description was like what you
Hmmm, well I'm not familiar with this yet newer error terminology proposal.
-- JonL --