Issue: HASH-TABLE-PACKAGE-GENERATORS (version 2)

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

I'll make another version of this proposal before Larry's ultimate deadline;
but first I'd like to see if there are any other reactions to these
comments.

re:     There is no guarantee that any state implicit in the invocation of the 
	form (<next-fn>) will survive outside the scope of the WITH-... form.
    The word "scope" here is a typo for "extent".  In addition, it's hard to
    figure out what this means, since it does not use the standard
    terminology for describing exceptions.  Why not say, "It is an error to
    evaluate the form (<next-fn>) outside the dynamic extent of the body of
    the WITH-... form"?

Both "scope" and "extent" are involved here -- the form  (<next-fn>)  is
defined only within the scope, and any objects which it may create have
validity only within the "extent" of the WITH-...  The reason I don't
want to use "It is an error ..." to describe the "extent" constraint 
is that the buzz phrase "It is unspecified" (from the "new" error 
terminology) is more appropriate here.  Implementations which don't use 
the Symbolics style "locking" might actually provide indefinite extent 
so that the Generators proposal will not be limited.


re: Clarify that <hash-table>, <package>, and <type> are only evaluated once.

Right.


re: The phrase `a boolean to indicate no more entries (T says "there are more")
    used in the description of the first value of the generator can be
    interpreted ambiguously.  ... this could be rephrased ... "it either 
    returns T and an entry, or NIL when all entries have already been returned"

Sounds good.


re: The syntax of WITH-PACKAGE-ITERATOR is rather baroque.  It has an optional
    subform (<package>) preceding a required subform (<type>), 

Yea, I didn't like that either.  An &optional is fine with me; Mlynarik
even suggested &key parameters.
								and it uses
    non-keyword symbols as flags, of which three are in the LISP package and
    two are not.  Here's a possible alternative that I think is cleaner:

I used exactly the names of the (extended) CLtL macros for iteration over
packages; e.g., 
  (defmacro do-external-symbols ((var &optional pkg result) &body body)
    `(with-package-iterator (next ,pkg 'do-external-symbols)
       ,@body)
The uniformity of implementing the DO-mumble-SYMBOLS seemed like a nice
mnemonic for "flag" choices; unfortunately, it appears that no one ever 
submitted the DO-PRESENT-SYMBOLS proposal, so that is why one is not in 
the Lisp package.  But it's no big thing, so I'll opt for keyword "flags"
if it will help acceptance of the proposal.


re:	  :ACCESSIBLE		;all symbols present or inherited
	  :PRESENT		;all symbols present in the package
          :EXTERNAL		;all symbols exported by the package
	  :INTERNAL		;all symbols present and not exported
	  :ALL			;all symbols in all packages

I might mention that Lucid's implementation has certain optimizations
such that doing the :EXTERNAL case is not at all performance-wise
equivalent to simpely doing the :PRESENT case and filtering out the 
internals.  Since it just may be that other implmenetations have similar
assymetries about the :INHERITED case, we should add it for completeness.


-- JonL --