Issue: DEFPACKAGE (version 2)

[Jon L White <jonl@lucid.com>]

re: ... I simply don't buy your arguments. ... 
    I think all your arguments are variations on: using symbols
    with package prefixes in a DEFPACKAGE form is more dangerous than
    using symbols with package prefixes in other forms.  My position
    is that DEFPACKAGE is no different from anything else in this respect.

Either you are not reading the same May criticisms, or you're not 
understanding them fully.  In very simplified form, they are:

  -- Everything done by :IMPORT can be done with :IMPORT-FROM; thus
     :IMPORT is redundant (and similarly for :SHADOWING-IMPORT).

  -- :IMPORT _requires_ symbols and cannot accept strings; thus
     :IMPORT-FROM has greater flexibility;

  -- At package-creation time the user can, with proper imports, virtually
     subsume all need for double-colon syntax in the remaining code; but 
     his purpose is defeated if he has to use double-colons in the creator 
     expression. [We discuss elsewhere how double-colons cause trouble].

Only one of the three arguments is about the danger of altering other 
random packages while merely *** reading in *** some package creator 
expressions.  I'm really surprised that you haven't seen this problem 
before, since DEFPACKAGE is in fact nothing beyond the capability now
in use of doing (PROGN (SHADOW...) (EXPORT ...) (USE-PACKAGE ...) ...)
[Incidentally, the problem is never caused by just "using symbols with 
package prefixes", but rather by using double-colon prefixes.  I'm sure
you're aware of that already.]

At least with top level calls to IMPORT, you can say either:
     (A) (import 'loser::bar)
     (B) (import (intern "BAR" "LOSER"))
     (C) (import (or (find-symbol "BAR" "LOSER") (error "Missing Symbol")))
but in the current state of the DEFPACKAGE proposal, there is no capability
equivalent to (B) or (C) for the :IMPORT option.  Hence the desirabililty 
of not adding a *dangerous* construct to the language when a harmless one
-- :IMPORT-FROM -- is already planned.


The point of all this not to say that defpackage as proposed is guaranteed
to cause irreconcilable name-conflict problems.   Rather, I think that the 
penalty for minor order-of-event mistakes should be a continuable error 
signalled before the damage is done, rather than the situation that Richard
Greenblatt described at the Fort Collins meeting.


The last mail interchange back in May concerned whether or not :IMPORT-FROM
should complain if the requested symbol didn't already exist, or whether
it should take the possibly dangerous step of creating it quietly.   A part
of that interchange is copied below, since it is highly relevant to the
"dangerousness" issue.



-- JonL --


  Date: Fri, 27 May 88 18:04:22 PDT
  From: Jon L White <edsel!jonl@labrea.stanford.edu>
  To: Moon@stony-brook.scrc.symbolics.com
  Cc: CL-Cleanup@sail.stanford.edu
  In-Reply-To: David A. Moon's message of Tue, 24 May 88 16:55 EDT <19880524205536.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
  Subject: [More on] Issue: DEFPACKAGE 
  . . . 
  re: Okay, you're proposing that :IMPORT-FROM be changed to do something
      different from any of the previous proposals, namely to call
      FIND-SYMBOL instead of INTERN or the secret version of INTERN that ...

  This is wrong.  Your message of "Wed, 23 Mar 88 14:49 EST", which was the
  presentation of (Version 2), said the following about :IMPORT-FROM (and
  :SHADOWING-IMPORT-FROM):

      (:IMPORT-FROM {(package-name {symbol}*)}*)
      (:IMPORT-FROM package-name {symbol}*)
	      Find the specified symbols in the specified packages and import
	      them into the package being defined.  The second syntax is a
	      convenient abbreviation when only one package is specified.
	      Note that only the name of each argument symbol is used.  The
	      actual symbol that gets imported is not necessarily the one
	      given as an argument; it's a symbol with that name accessible in
	      the named package.

  "Find the specified symbols" --  not "INTERN".    Maybe the Symbolics 
  implementation does call INTERN, and you were thinking of that rather 
  than the DEFPACKAGE proposal?


  -- JonL --