[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: HASH-TABLE-PACKAGE-GENERATORS (version 2)
- To: Moon@STONY-BROOK.SCRC.Symbolics.COM
- Subject: Issue: HASH-TABLE-PACKAGE-GENERATORS (version 2)
- From: Jon L White <firstname.lastname@example.org>
- Date: Fri, 7 Oct 88 16:37:53 PDT
- Cc: email@example.com
- In-reply-to: David A. Moon's message of Fri, 7 Oct 88 14:00 EDT <19881007180006.0.MOON@EUPHRATES.SCRC.Symbolics.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
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.
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"
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
(defmacro do-external-symbols ((var &optional pkg result) &body body)
`(with-package-iterator (next ,pkg 'do-external-symbols)
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 --