Non-yucky package names (I think)

[David A. Moon <Moon at SCRC-TENEX>]

    Date: Tue, 31 May 1983  03:14 EDT
    From: Scott E. Fahlman <Fahlman@CMU-CS-C>
    New proposal:

    Flush the rules for package-name caseification that are found in the
    current package chapter.  Replace it with the following:

    With respect to case, reading, and printing, package names are treated
    EXACTLY like symbol names: upcase by default, escape that using / or ||,
    observe *PRINT-CASE* on printing, look up using case-sensitive matching.

    Note, however, that package names do not become symbols, but are
    stashed away in the package object as a string, after case conversion
    paralleling that for symbol-names.

    So the reader reads a token in just as if it were a symbol.  If it hits
    a : or #:, it doesn't call INTERN on the token just collected, but
    instead calls FIND-PACKAGE.  Then it reads the following token, which
    had better be a symbol, and interns it.

    The various package functions that take package-name strings should
    probably take symbol-or-string.  If a symbol, you get the
    case-conversion for free but create a random symbol in the current
    package; if a string, you have to be careful of case.

All the above sounds completely right to me.

    So, |fOo:BaR| would be a symbol containing a colon, but |fOo|:|BaR|
    is symbol |BaR| in package |fOo|.  Notice that I have nothing up my
    sleeves and at no time did my hands ever leave the keyboard.

I'm not so sure about allowing vertical bars in package prefixes.  It depends
on whether you think of vertical bar as an alternate form of backslash
or as a separate reader-macro whose output is by definition a symbol
(not a token).  I could stand this either way, but would slightly prefer
to avoid the complexity of allowing vertical bar in package prefixes.

    What we lose is the cute preservation of original case in package names
    and the ability to toss around package-name strings without worrying
    about case.  What we gain is a lot of uniformity: both halves of a
    symbol behave the same way.

We could still do case-independent lookup of package names in FIND-PACKAGE
(hence in USE-PACKAGE, export, etc.) and require that no two distinct packages
have names that differ only in case.  This would eliminate the need to be careful
about case when typing package names as strings.