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

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

re: ...could you explain why the syntax should be made more complicated to
    deal with the special needs of a particular implementation?  ...

I don't think either syntax is superior enough to warrant spending time
trying to figure out compiler optimizations.  After all, this fool 
function is definitely _not_ for the masses --  it is being designed
for precisely the 3 or 4 hackers who are working on portable iteration
paradigms; and they will use it in precisely three or four places
in their code.

Also, I think you are overestimating the complexity of what the current
SSC's[*] in our community can handle.  By making the iteration scope
macro define a 'macrolet' name, the implementor can put lots of
"smarts" into that one macro.  But expecting the compiler to do
enough source code analysis to figure out that when a bound variable
has a certain value, nothing "interesting" will be done ... I just
can't believe you're actually suggesting this.  And it's not just
the compiler -- people *do* run code interpretively, you know!

The particular thing I was referring to in Lucid's DO-EXTERNAL-SYMBOLS
is that Lucid represents packages differently depending on the ratio of
of internal and external symbols.  [This is consistent with good data
base design -- you have several "baskets" to use, depending on how big 
a fish you want to carry home.]  But even without Lucid's particular
optimizations, consider doing a DO-INHERITED-SYMBOLS over a package
MONGO, that uses LISP; and suppose MONGO is a "development" package 
with 80,000 internal symbols present.  Would you really want to iterate
through 79,000 internal symbols, swapping in all those jillions of
pages, before finding the desired 1000?  Probably not.  Any 
implementation -- not just Lucid's -- that takes the obvious step of
iterating thru the package-use-list and ignoring certain shadows would
be infinitely better than requiring user-level code to do filtering of
all accessible symbols.  This is *not* a LUCID-specific issue.


Even if I were to agree that your alternative #2 is minutely simpler 
than alternative #1, the point is that #1 is "real good" all by itself;
and this doesn't feel like a place where 50.001% is that much better 
than 49.999%.



-- JonL --



[*] SSC = "Sufficiently Smart Compiler"