Issue: PACKAGE-FUNCTION-CONSISTENCY (Version 1)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

 From my list of "pending issues" distributed at the last X3J13 meeting...

-----
Issue:        PACKAGE-FUNCTION-CONSISTENCY
References:   11.7 Package System Functions and Variables (pp182-188)
Category:     CLARIFICATION/CHANGE
Edit history: 21-Oct-88, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  CLtL is vague about whether either or both of package or package name
  are permissible in some cases.

Proposal (PACKAGE-FUNCTION-CONSISTENCY:PERMISSIVE):

  Clarify that it is permissible to pass either a package object
  or a package name (symbol or string) in the following situations:
    - the :USE argument to MAKE-PACKAGE or IN-PACKAGE
    - the first argument to IN-PACKAGE, FIND-PACKAGE, and RENAME-PACKAGE
    - the second argument to INTERN, FIND-SYMBOL, UNINTERN
    - the second argument to EXPORT, UNEXPORT, IMPORT,
      SHADOWING-IMPORT, and SHADOW
    - the first argument (or a member of the list which is the first
      argument) to USE-PACKAGE or UNUSE-PACKAGE.
    - the PACKAGE argument to DO-SYMBOLS.
    - the PACKAGE argument to DO-EXTERNAL-SYMBOLS.
    - the PACKAGE argument to DO-ALL-SYMBOLS.

  If FIND-PACKAGE is given a package object as an argument, it simply
  returns it.

  If IN-PACKAGE is given a package object as an argument, that package
  is selected. It is an error if, when a package object is given as a
  first argument to IN-PACKAGE, a :USE list is explicitly specified and
  does not exactly match the package or :NICKNAMES is explicitly supplied
  and does not exactly match the package.

  Clarify that the functions PACKAGE-NAME, PACKAGE-NICKNAMES, 
  PACKAGE-USE-LIST, and PACKAGE-USED-BY-LIST are (at least conceptually)
  accessors to package data structures and permit only package objects
  as arguments.

  Clarify that the function MAKE-PACKAGE permits only a package name
  as an argument since it does not make sense to create an existing
  package.

  Clarify that package nicknames must always be expressed as package
  names (symbols or strings) and may never be actual package objects.

Test Case:

  (INTERN "FOO" "KEYWORD") => :FOO

  (DEFVAR *FOO-PACKAGE* (MAKE-PACKAGE "FOO"))
  (RENAME-PACKAGE "FOO" "FOO0")
  (PACKAGE-NAME *FOO-PACKAGE*) => "FOO0"

Rationale:

  This makes things more consistent.

Current Practice:

  Symbolics Genera permits strings as package names.
  Symbolics Cloe does not permit strings as package names.

Cost to Implementors:

  Very small.

Cost to Users:

  None. This change is upward compatible.

Cost of Non-Adoption:

  Implementations would continue to vary gratuitously, leaving a potential
  for portability problems.

Benefits:

  The cost of non-adoption is avoided.

Aesthetics:

  This makes things more regular, and so presumably more aesthetic.

Discussion:

  Pitman ran across this problem while trying to port Macsyma to various
  implementations. Discussion with other maintainers of portable programs
  shows this is a common source of aggravation in portable code.

  Since the pathname accessors all take namestrings or streams, one might
  easily argue that it would be more consistent for PACKAGE-NAME, 
  PACKAGE-NICKNAMES, etc. to also take arguments of package names. After
  all,
   (PACKAGE-NAME "FOO") => "FOO"
  is no stranger than
   (NAMESTRING "JOE:fred.lisp") => "JOE:fred.lisp".
  If anyone wants to see a redraft of this to include even these
  functions, they should speak up.

  It would be possible to say that MAKE-PACKAGE took package objects as
  arguments and just returned that package. That might have limited
  usefulness on rare occassions, but mostly seemed too far out in left
  field to bother suggesting it.