[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: INTERN and "intern" -- the unwise choice of terminology
- To: common-lisp@SU-AI.ARPA
- Subject: Re: INTERN and "intern" -- the unwise choice of terminology
- From: Nick Gall <Gall@MIT-MULTICS.ARPA>
- Date: Thu, 4 Apr 85 21:06 EST
- In-reply-to: Message of 4 Apr 85 10:42 EST from "Rob MacLachlan"
Date: 4 April 1985 10:42 est
From: Rob MacLachlan <RAM at CMU-CS-C>
Subject: INTERN and "intern" -- the unwise choice of terminology
I don't think that a home-package-setting operation is well
defined, at least without some constraints. The system would
certainly get confused if you set the home package to a package that
the symbol was not accessible in, and it would be dubious to set the
home package to a package where the symbol is not present (as opposed
to inherited).
If you impose these requirements, setting the home package starts
to sound a great deal like IMPORT. I think that the proposal to have
IMPORT set the home package if there is none makes a great deal of
sense. The effect of IMPORT is really about the same as old-style
intern on a symbol. I don't really like the idea of INTERN having
obscure side-effects such as setting the home package, since it is
something that the system often does without an explicit request.
Rob
I prefer this proposal to White's `setf with constraints' proposal.