Issue: DEFPACKAGE (version 2)

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

re: There's been no discussion on this proposal since 8 Jun, when it was 
    distributed in draft form to X3J13. I am taking this to mean that people 
    are not unhappy with the version of 23-Mar-88 -- at least not unhappy 
    enough to complain or suggest improvements.

Not so.  When you distributed the draft in June, I reminded you then that
I had serious objections to one part of this proposal, and that moon
hadn't addressed them satisfactorily at that time.

A series of messages took place on "Cleanup" after I sent out the one
reproduced below.  Moon acceeded to the first point one, but never came 
to any resolution about point two -- to flush two redundant and *dangerous*
options :IMPORT and :SHADOWING-IMPORT.   There still has not been a revised
version of the proposal circulated; presumably the revision should wait 
until the second point is resolved.


-- JonL --

-------------------------------------------------------------------------------

    Date: Tue, 17 May 88 02:05:55 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 Wed, 23 Mar 88 14:49 EST ...
    Subject: Issue: DEFPACKAGE (version 2)

    There is one very dangerous loophole in this proposal, which could be
    trivially plugged up.  The issue is whether symbols are a critical
    arugment to any of the options, or whether "names" would be satisfactory.
    What would you say to the following alterations:

      (1) Change most uses of the meta-variable {symbol} to {name}, with
	  an explicit statement that such a {name} must be either a string,
	  or a symbol.  Thus the description of :IMPORT-FROM would go from 
	    (:IMPORT-FROM {(package-name {symbol}*)}*)
	  to
	    (:IMPORT-FROM {(package-name {name}*)}*)
	  or maybe even
	    (:IMPORT-FROM {(package-name {symbol-name}*)}*)
	  Change also the phrase "Note that only the name of each argument symbol 
	  is used." to something like "Note that only the name of each argument
	  is used; if a symbol is passed, its symbol-name is used".

      (2) Flush the two options that require symbols, as opposed to names --
	  namely :IMPORT and :SHADOWING-IMPORT.  Note that these are the only 
	  two that don't have the phrase "Note that only the name of each 
	  argument symbol is used." in their description.  These two options 
	  are superfluous since their functionality is completely covered by 
	  :IMPORT-FROM and :SHADOWING-IMPORT-FROM.

    The :IMPORT option as currently specified makes it all too easy to violate 
    reasonable package modularity rules -- e.g. (:IMPORT foo::bar) -- without 
    considering the warning given on CLtL p175 (top of page) "... since 
    accessing an internal symbol of some other package is usually a mistake".
    Much worse, I've seen even very experienced hackers (more than 10 years
    experience) fall into the trap of thinking that FOO::BAR means "access
    the internal symbol BAR in the FOO package", or "access the symbol BAR
    present in the FOO package, regardless of whether it is external or not".
    The disaster that occurs once in a long while is that merely reading in
    FOO::BAR creates some imposter symbol in the BAR package that shouldn't
    be there at all; but the poor loser who does this doesn't find that out
    until a much later time, when a USE-PACKAGE or EXPORT is done.  And of
    course by the time he finds it out, there is little hope of ferreting
    out all the structures already read-in that point to the bogon symbol.

    It may be too much to ask that the :IMPORT-FROM option signal an error
    if no symbol of the requested name is available in the specified package.
    This would (desirably, I think) differ from the reader's action when 
    parsing a double-colon notation.  But at the very least, why add the 
    :IMPORT and :SHADOWING-IMPORT options that *require* symbols as opposed to 
    names?  Why, when there are perfectly good alternatives that don't have 
    the modularity-violating implications described above?


    If these two alterations are made, then a DEFPACKAGE can be written with
    all data specified as strings; and in the cases when symbols are actually
    are supplied, then the compiler can convert them to strings as they are
    put out into the fasl file. (Essentially the same compiler conversion
    takes place now in Symbolics treatment of SHADOW, and in Lucid's 3.0
    release version of SHADOW).



    -- JonL --

-------------------------------------------------------------------------------