% cat foo.lisp
(defpackage foo
  (:export x))
(in-package :foo) ; cmucl likes a keyword here for some reason
(setf x 10)
% clisp
[1]> (load "foo.lisp")
;; Loading file foo.lisp ...
;; Loading of file foo.lisp is finished.
T
[2]> (use-package :foo)
... error: X is already interned in COMMON-LISP-USER

Of course, (import 'foo:x) gives the same error, which also happens on cmucl.
(find-symbol "X") claims that it is internal to USER, but X is neither bound
nor fbound in USER (foo:x works as I expect).  I suppose (based on my vague
understanding of how symbols work), there's no need for a symbol to have a
value, function, plist, or whatever to be interned, it merely needs to be
mentioned.  This sort of thing seems like it would easily create spurious
name clashes (when you import a symbol you previously mentioned in a QUOTE), so
maybe that's not how it works.  Anyway, it still doesn't explain where the
USER package is getting those symbols.

 (cl:defpackage cl-user::foo
   (:export cl-user::x))

This will be interpreted as

 (CL:DEFPACKAGE "FOO"
   (:export "X"))

but as a side-effect, you have created CL-USER::FOO and CL-USER::X.

The defpackage defines a package named "FOO".

IN-PACKAGE does not evaluate its argument.  It used to.
Some implementations get worried if you say (in-package foo) that
you are trying to name a variable; using a self-evaluating expression
like "FOO" or :FOO or :foo works best.

In doing this USE-PACKAGE, you are trying to make CL-USER inherit FOO:X
but there is already a CL-USER::X (see above).  That conflict has to be
dealt with.

Solution?

Use

 (defpackage "FOO"
   (:export "X"))

Don't be making symbols you don't mean to use.

I prefer something like this:

(defpackage :foo
  (:export #:x))

There was a long, drawn out thread about this last
year, wasn't there?

I have a suspicion you're actually confused on this, but I can't tell
for sure by the way you're expressing yourself.  The example below
suggests a confusion.

You're welcome to suggest whatever weird style you want.
I just abhor this particular style.

Making extra gensyms to throw away seems silly.

Making extra symbols in the keyword package seems equally confusing
and pointless to me.

As far as I know, this style was developed by people who want to stick
their head in the standa nd not acknowledge that the normal internal
case is, in fact, uppercase.  I don't think the issue is that it might
not be uppercase--it's that they _wish_ it might not be.

Which also makes me wonder why symbols work at all.  CLOCC code uses:

(in-package :cllib)

Even given that a symbol is accepted as a package designator, I still don't
understand why a keyword would also designate the same package, since :X and
X are different symbols.

Is there any reason to prefer:

(defpackage "FOO"
  (:export "A" "B" "C"))

over:

(defpackage "FOO")
(in-package :foo) ; or "FOO"?
(export '(a b c))

As a user, I do something protective like that just so I'm not
potentially screwed if for some reason it does change.  This doesn't
indicate I want it to change, but if some vendor has made noises
that suggest it may want to do that I am going to be careful.
The cost is minimal.

  Then you are not using ANSI Common Lisp, but some other Lisp.

| I prefer something like this:
|
| (defpackage :foo
|   (:export #:x))
|
| There was a long, drawn out thread about this last year, wasn't there?

  I have tried long and hard to understand the position that (1) ANSI
  Common Lisp mandates upper-case symbol names, (2) someone does not like
  that, so (3) violating ANSI Common Lisp requirements is the only
  solution.  It most definitely is not the _only_ solution.

  If you are a good citizen of the Common Lisp community, you realize that
  it does not matter at all what the internal case of the symbols are.  If
  you want to see and type lower-case symbol names, that has no bearing on
  what the internal symbol names must be.  Thinking it does indicates a
  massive failure to grasp how the whole string-to-symbol operation works.

  I am probably no more than a few days away from a fully working solution
  that would make Allegro CL, which has introduced this problem to our
  community, work equally well with _both_ upper-case and lower-case symbol
  names in the code it reads and its programmers are exposed to.  Today,
  you are required to make a decision whether you want your code to see
  upper-case _or_ lower-case symbol names.  This has been a source of some
  very serious annoyances and even "wars" here, but it has at its root a
  personal dislike of the arbitrary choice of upper-case symbol names and a
  lack of professionalism by those who hold this personal grudge against
  the standard.  I believe I have found an easy, modular, and predictable
  way to make the programmer choose, so the implementor does not have to.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

  Paul, you have solved the wrong problem and have just created another,
  much more serious one: fear of trusting the standard.  This is a very
  contagious fear and once started, can cause you to become paranoid in the
  extreme about trusting a language standard.  Bugs in implementations are
  no longer bugs, they _may_ be intentional violations that you have to
  take into account in much more serious ways than bugs -- they are likely
  to last.  Some vendors want you to live in this fear all the time, but
  the primary such fear-monger is fortunately not interested in Common
  Lisp.  In my view, it is not a good sign at all when a vendor works
  against the community standards, and almost even worse when they give you
  a choice of departing from the standard with them or not, especially when
  you sort of have to depart with them to get their new features.  I am not
  at all impressed with these tactics and their effect on people, which is
  why I have spent a huge amount of time trying to find alternative
  solutions that do not cause people to live in fear and engage in counter-
  measures to prevent painful brushes with vendor-initiated violations.

| Yes, I remember which side of that long thread you were on. :)

  The "side" Kent and I are on is: as a vendor, DO NOT VIOLATE THE STANDARD
  just because you have a personal opinion or grudge against the committee
  decision to use upper-case symbol names.  It is essentially arbitrary,
  and if you need a different solutions, make it coexist with the standard.

| As a user, I do something protective like that just so I'm not
| potentially screwed if for some reason it does change.

  You mean, if your vendor is not particularly interested in letting you
  continue to work with ANSI Common Lisp?

| This doesn't indicate I want it to change, but if some vendor has made
| noises that suggest it may want to do that I am going to be careful.  The
| cost is minimal.

  The cost should be zero.  If your vendor makes fully conforming code stop
  working, they have transferred the cost of their decision to you.  If
  they do this to you, you have to weigh that cost against the cost of
  using a different vendor.

  I believe I have found a way to make the cost exactly zero to programmers.
  It does require some investment by the vendors, however, but this is how
  responsible people generally do language development.  What has taken me
  so long is figuring out how to make this investment small enough and the
  obvious benefits large enough that people will want to make make it.

  My _personal_ opinion is _also_ that lower-case symbol names look far
  more "modern" than upper-case symbol names, but I actually value my own
  professionalism towards specifications much higher than my personal
  opinion, so I have to accept that the symbol-names are upper-case until I
  can convince people that the specification should be changed, and when it
  is changed, that no previously conforming program would break.  To make
  this even more palatable to users of other implementations than those I
  have the ability to influence, a solution has to be made available that
  all users can load into their Common Lisp systems and expect to work.  I
  care enough about this issue to have spent a few months on this rather
  than just go ahead and violate the standard by flipping the case of all
  the characters of all the symbol names in the Common Lisp image and ask
  the rest of the world to deal with it.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Fortunately, Franz seems so far to like the plan I proposed for how to
resolve this in a CL-compatible way in their products, and there is
some hope that in the future this will be resolved.  (Unless as they
try to implement my suggestion they run into a snag that none of us
has seen yet.)

  There are serious snags in this area.  I believe I have worked them out.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

CL-USER(1): (symbol-name '|aBc|)
"aBc"
CL-USER(2):

(DEFUN FOO (X)
  (BAR X))

but instead type your program in this way:

(defun foo (x)
  (bar x))

that you might then use the same reasoning to type your defpackage
form in lowercase and have it come out right:

  (:export #:x)

instead of

  (:export #:X)

or

  (:export "X")

  (:export x)

and

  (:export :x)

are wasteful.

  string designator n. a designator for a string; that is, an object
  that denotes a string and that is one of: a character (denoting a
  singleton string that has the character as its only element), a
  symbol (denoting the string that is its name), or a string (denoting
  itself).  The intent is that this term be consistent with the
  behavior of string; implementations that extend string must extend
  the meaning of this term in a compatible way.

I'm very glad this piece of terminology is in there, because "string
designator" is a useful concept.

  I have some wrinkles to iron out and some real life testing to do, so the
  timing of Paul F. Dietz' comments were slightly infavorable.  Franz Inc
  will be the first to know how about this, as you probably will be the
  only ones to seriously put it to the test, too.  :)

| I have not had a chance to work on this (and have told Kent as much)
| because I am deep into buttoning up our 6.2 version, which has been
| essentially feature-frozen after beta release.  But I am of course
| interested in seeing a solution for the future (it would also be nice if
| it were patchable).

  It should be patchable for either image, but my primary goal has been to
  give you a very good reason not to distribute two different images, as it
  causes people to choose the lower-case image when all they want is some
  of the features that some of your programmers only think will "work" with
  in lower-case, and offer some fairly ridiculous arguments to the effect
  that it is "necessary".  My goal has been to make it as easy to choose
  whether you see upper- or lower-case symbols as to set the readtable-case
  or the *print-case* variable.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

...

"a symbol or a string or a list of symbols or a list of strings"

were both more wordy AND incorrect (because they often omitted "a list of
mixed symbols and strings") than the resulting:

"a designator for a list of string designators"

But the other important aspect of the change is that any phrase as
textually compact as "a symbol or a string" still has an "or" in it, and
that means any use of "or" to conjoin phrases or clauses in the sentence
is arbitrarily harder to make work because you have to use ", or" or "; or"
or you have to just give up and go to multiple sentences.

CASE FIGHT!!!!!!!!

"Paul F. Dietz" <di...@interaccess.com> writes:

Now.  A backward compatible solution can be specified (shameless
plug), but it requires agreement by the implementors to provide it.

The above style placates Franz case sensitive images, but it is
arguably unpleasant and it is guaranteed to work well only in ACL.  It
does work in any CL, but, e.g. you do not have any guarantees that the
uninterned symbols get collected.

Cheers

So whatever the implementation, the form

 (:export #:x)

would have similar nature wrt gc to

 (:export "X")

since if the defpackage form does not let go of the #:x it would also
not let go of the "X".  Now, of course there is the possibility that
the symbol x has not yet been created, and so "X" in the export list
might be used for the symbol-name during the subsequent intern of x
before its export.  However, the possibility exists to use
(symbol-name '#:x) in the same way.  So the gc characteristics
of the two specifications are the same, with the exception that the
temporary allocation of #:x is larger than "X", if not optimized.

So in conclusion, I would hope that any defpackage implementation
would allow its entries to be gc'd (modulo the interning usage I
cited) whether it is an uninterned symbol or a string.

i have, quite coincidentally, recently received a note from a lisp user
who was confounded in his effort to use an application by problems with
symbol name case. it was most amusing that, in keeping with the
respective lisp vendor's documents on the subject, the enquiry was
phrased in term of what one should do to make the application code
'portable'." i had always presumed that "portable" would be confined to
runtime behaviour which itself conforms to "the standard".

the initial issue concerned symbol name case in code. i see some value
to the "mixed case" style of capitalization, which can cause problems
with some modes of case sensitivity. the lisp in question can be
configured to accommodate mixed case style, so that is a minor issue.

beyond that, there are some cases where the upcased and literal cased
symbols in the same package are assigned distinct meanings. this
applies, for example, with function and/or class definitions generated
from external, non-lisp definitions. in order for this to work, intern,
defpackage, and read/print should all have readily predictable effects
as to the internal and external representations of objects which they
manipulate. i would have been less likely to use that method if it were
not trivially possible to predict the internal symbol name case in a
conforming lisp.

aside from my general curiosity about the possible advantages of
permitting the programmer to predict the effects of thirty-six possible
combinations of symbol case, readtable case, and print case, i am
concerned whether everything which can be expressed in any given mode
can also be expressed "portably". in particular, can everything which
can be expressed in the mode which conforms to ansi behaviour also be
expressed portably.

has there been any discussion on that question?

"... less likely to use that method were it not trivially possible to
 predict the internal symbol name case in a conforming lisp."

with the addition of case modes, prediction is still possible, but it is
no longer trivial.
this aside from issues of conformance.

i was just wondering if there's more behind this.

I can't personally feel any great sympathy for anyone who takes the bait
and uses the vendor-specific option that says  "I will make your life
difficult if you use any vendor other than me" and then you find later
that your life is difficult.

This is just not a difficult problem.
SUGGESTION: JUST DON'T USE NON-PORTABLE STUFF.

There is simply no good programming need for non-portable naming.
It is a contrived problem.  If you use naming that doesn't interlock
correctly with other programs, you may find that things don't interlock with
other programs.  Is this a surprise?

I beleive that Franz's documentation tries to distinguish either by
phrasology or by context whether we are talking about portability in
the ANSI CL sense, or in the more generic sense.  Where we talk about
case portability, for example, we do not generate a link to the CL
definition of portability.  And we try to be specific about what kind
of portability we are describing.  For example, in

http://www.franz.com/support/documentation/6.0/doc/case.htm#portabili...

we say "If portability of your code between the various case modes is
important, here are some things you should do"...

But also, we talk of portability for compatibility packages, like the
older defforeign interface working with the newer def-foreign-call
interface, or portability between Windows and Unix despite the different
line-ending techniques they use.

None of the usages of the term are necesssarily mutually exclusive, and
one can write a case-portable program which is also portable in the ANSI
sense that it conforms to ANSI specs.

Of course, I am not arguing that it is impossible to write a case-sensitive
program that is not ANSI compliant (e.g. with usage of the same words which
vary only in case), but such a program is by definition not case-portable
(i.e. it won't work in both case-sensitive-lower lisps and ANSI lisps).
The documents we write about such case-portability are designed to show
a programmer how to write in a style that will work in both implementations.