Incorrect behavior of IMPORT with "homeless" symbols

Bug #1645895 reported by Gerd Heber
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
SBCL
Won't Fix
Undecided
Unassigned

Bug Description

;;; The documentation for the IMPORT function
;;; http://clhs.lisp.se/Body/f_import.htm#import
;;; 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)

Tags: ansi
Revision history for this message
Stas Boukarev (stassats) wrote :

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.

Changed in sbcl:
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.