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

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

    Date: Thu, 10 Nov 88 13:26:05 PST
    From: Jon L White <jonl@lucid.com>

    Your alternative syntax #1 is clearly superior to all the others.  Could 
    you take the time to alter the proposal accordingly, and at the same time 
    fix the typo "available" into "accessible"? [and also proof read the 
    whole proposal again?]

Before I take the time to do that...

    Alternative #2 is unacceptable, because it presumes that filtering a
    DO-ALL-SYMBOLS is a reasonable implementation of DO-EXTERNAL-SYMBOLS.  
    In fact, in Lucid Common Lisp, the situation is much more complex; the 
    "filtering" step could, in extreme circumstances, become pragmatically 
    unworkable, whereas the native implementation has no trouble.

...could you explain why the syntax should be made more complicated to
deal with the special needs of a particular implementation?  It might be
that I don't understand just what these pragmatic unworkablenesses are,
and don't understand whether they are peculiar to Lucid or more general.
However, my immediate inclination is to suggest that Lucid's
implementation of WITH-PACKAGE-ITERATOR should check for and optimize
cases that look like

  (WITH-PACKAGE-ITERATOR (next-symbol package)
     ...
     (MULTIPLE-VALUE-BIND (valid symbol flag) (next-symbol)
       (WHEN valid
	 (WHEN (EQ flag :EXTERNAL)
           ...))))

Of course you don't want to look for that one particular source pattern,
what you want to look for is cases where no side-effects are affected by
suppressing returning of the internal symbols.

This is a somewhat complicated optimization but surely well within the
capabilities of Lucid's compiler writers.

Also, MLY had a good suggestion, which was that instead of having
special cases for one package and all packages, the macro should simply
accept a list of packages.  An implementation can of course recognize
and treat as a special case forms such as
  (WITH-PACKAGE-ITERATOR (next-symbol (LIST-ALL-PACKAGES)) ...)
and forms such as
  (WITH-PACKAGE-ITERATOR (next-symbol (LIST package)) ...)
We could also allow a single package in place of a list if we think that
convenience is worthwhile; USE-PACKAGE is a precedent for this.  This
eliminates the oddity of the optional argument that you omit to tell it
to do all packages.

If we adopt this suggestion I will feel better about having keyword
arguments for which symbols to access, although I still feel the simpler
syntax with no options is preferable unless you can show me that Lucid's
needs outweigh the desire for syntactic simplicity.