Importing a symbol into KEYWORD should make it act like a keyword

[Paul F. Dietz]

* (defpackage :foo (:use) (:export "BAR"))
#<PACKAGE "FOO">
* (import 'foo:bar (find-package "KEYWORD"))
T
* 'foo:bar
FOO:BAR
* foo:bar

==> error, foo:bar is unbound

However:

Importing a symbol S into package P counts as "interning" it in that package (see glossary defn of intern, and the text for the unintern function.) And for the keyword package:

"Interning a symbol in the KEYWORD package has three automatic effects:

1. It causes the symbol to become bound to itself.
2. It causes the symbol to become an external symbol of the KEYWORD package.
3. It causes the symbol to become a constant variable."

So, foo:bar should have become a constant that evaluates to itself when it was imported into the keyword package.

There are subtle issues here with the different between a symbol being accessible in a package, being present in the package, and having the package as its home package. All three of these are distinct concepts.

Additionally: calling (intern "BAR" (find-package "KEYWORD")) in this
example returns the symbol without doing any of those automatic things either.

[Douglas Katzman (dougk)]

It's not clear that the use of the word "Interning" in the sentence "... has three automatic effects" refers to any action other than specifically calling INTERN.

I realize that you disagree, but my testing shows that ECL, ABCL, CMUCL, and Allegro all take "Intern" to mean specifically calling INTERN. They all report that FOO:BAR is unbound; I think we should be consistent with that.

[Douglas Katzman (dougk)]

I just checked CLISP as well and it says unbound; but the behavior differs in one regard with the others: if the symbol being imported had no home package, then it becomes constant and eq to itself.

So it seems like the evidence is fairly compelling that this hair-splitting behavior is not well-defined, and changing it would make SBCL agree with CCL but disagree with others.

As to (intern "BAR" (find-package "KEYWORD")) not doing the three actions automatically, it doesn't do them if the symbol was already imported without doing them, thereby returning a found symbol; all 5 other implementations agree with this as far as I can tell.

[Paul F. Dietz (paul-f-dietz)]

The glossary gives this definition for intern:

intern v.t. 1. (a string in a package) to look up the string in the package, returning either a symbol with that name which was already accessible in the package or a newly created internal symbol of the package with that name.

So "intern"ing, as defined in the glossary, includes the case where the symbol's home is some other package. It is not just the case where the symbol did not exist, and has now just been created.

One might argue this is interning a STRING, not a symbol. However, it is clear that after interning a string, it need not be the case that the symbol-package of the symbol is the same as the package into which the string was interned.

[Douglas Katzman (dougk)]

There are too many semantic problems whichever direction this is resolved in.
* (defconstant x 'y)
* (import 'x 'keyword)
Should this: (1) signal a continuable error, (2) actually do the reassignment (regardless of how the user resolves the error), or not do the import?
I really don't think people have any expectation on importing symbols into keyword.

And I just now tested CLASP as well now, and it sides with the majority opinion.

I added a comment a year ago that we should consider whether to do what this bug report suggests (https://sourceforge.net/p/sbcl/sbcl/ci/22eed99c2d).
But at the time, I didn't do any testing on other implementations. Now I see we're not alone.

[Paul F. Dietz (paul-f-dietz)]

As an interesting aside, consider the case of a symbol that is present in some package P, but the symbol has no home package. Does importing that symbol into P set its home package to P? There are two sentences in the page for IMPORT that contradict each other.