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

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

I favor this for the most part, but it needs some corrections.
I hope you get this mail before Monday, as I won't be at the meeting.

    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"?

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

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.  The example makes it clear that the value returned
for the last hash-table or package entry is T, but a reader could think
that the intention was that NIL is returned with the last entry.  Perhaps
this could be rephrased in terms of the validity of the second and third
values?  Or in words such as "it either returns T and an entry, or NIL
when all entries have already been returned."

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

  WITH-PACKAGE-ITERATOR ((<next-fn> <type> &optional <package>) &body body)     [Macro]

  Within the lexical scope of 'body', the name <next-fn> is defined
  via MACROLET such that each invocation (<next-fn>) will return
  the successive items from the package which is the value of the
  expression <package>.  Iterating over such a form will thus make the
  contents of the package available one at a time.  The <type> argument
  may assume any of the following values, indicating the sort of 
  symbols wanted:
	  :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
  <package> is required unless <type> evaluates to :ALL, then <package>
  can be omitted.

One could debate the set of types provided, e.g. removing :INTERNAL
or adding :INHERITED.  I don't care about that.