Incorrect behavior of IMPORT with "homeless" symbols
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
SBCL |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
;;; The documentation for the IMPORT function
;;; http://
;;; states:
;;;
;;; "... If any symbol to be imported has no home package (i.e.,
;;; (symbol-package symbol) => nil), import sets the home package of
;;; the symbol to package.
;;;
;;; If the symbol is already present in the importing package, import
;;; has no effect."
;;;
;;; This can be read as: If a "homeless" symbol is already present in the
;;; importing package, import has no effect.
;;; The example below puts that to the test and the behavior is inconsistent
;;; with that reading.
;;; The expected output is
;;;
;;; NIL
;;; NIL
;;;
;;; but it returns (SBCL 1.3.12 Linux AMD64)
;;;
;;; NIL
;;; #<PACKAGE "COMMON-LISP-USER">
;;;
;;; Not sure what going on here.
(defpackage "P1" (:use :cl))
(in-package "P1")
; intern a few symbols
(defvar my-list '(symb1 symb2 symb3))
; import symb3 in :cl-user
(import 'symb3 :cl-user)
; make symb3 "homeless"
(unintern 'symb3 "P1")
; confirm status
(print (symbol-package 'cl-user::symb3))
; import it a second time in :cl-user
(import 'cl-user::symb3 :cl-user)
; check status
(print (symbol-package 'cl-user::symb3))
(sb-ext:exit)
There are two sentences that prescribe different things. Even though the second one is a bit more strong, it's not entirely unambiguous. And it makes for a surprising behavior that depends on the symbol being present or not.
It seems more that the intention was that if the symbol is already present in the internal symbol list it doesn't need to do anything.
I don't think anyone wants this to apply to the rehoming bit as well.
Moreover, if it's indeed implemented as a no-op then to actually get the current behavior it would have to be first uninterned, which would also remove it from the shadowing list, so it would have to remember and reshadow it.
Clearly, the current behavior is more logical and useful.
I'm choosing to interpret this slight ambiguity in favor the status quo.