Re: Issue: DEFPACKAGE (Version 7)

[peck@Sun.COM]

>After re-reading the discussion, I think the only issue is to define
>explicitly what "at variance with the current state of that package" means.

I'd like to make sure that it is possible to define mutually
dependent packages using DEFPACKAGE.

What i envision is using TWO passes with DEFPACKAGE for each package.
The first pass defines symbols that are interned (home-package) in that package,
 ie, using :SHADOW, :INTERN, :EXPORT
and a second pass which enables access to symbols homed in other packages
 ie, using :SHADOWING-IMPORT-FROM, :USE, :IMPORT-FROM,
     and possibly :EXPORT them to users of this package

Yes, i have seen applications where this is used and useful.

This disciplined used of two DEFPACKAGE forms on the same package
should enable creating the desired package and symbol-inheritance structure.

Doing this with two DEFPACKAGE forms should not produce any state
which is "at variance" with the state of the package, no?

For example of a small fragment:
(DEFPACKAGE main	; pass 1, intern symbols homed in MAIN and UTIL
	(:export 'main1))		; for :USE and :IMPORT-FROM

(DEFPACKAGE util
	(:export 'util1))		; create and export to USEr's of util

(DEFPACKAGE util	; pass 2, now import or otherwise inherit symbols
	(:import-from main 'main1)	; inherit main:main1
					; for programmers in-package UTIL

(DEFPACKAGE main
	(:use 'util)	; programmers in MAIN will want access to all UTIL:syms
	(:export 'util)); USEr's of MAIN will expect access to UTIL1.
			; and may not even know of package UTIL!


I strongly support the view that DEFPACKAGE should be constructed
out of the existing primitives, and let the concept of "at variance"
be determined by when those primitives detect incompatible package changes.

[it is true that in this example the two forms for (DEFPACKAGE util...)
 could be coalesced into one.]