[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: HASH-TABLE-PACKAGE-GENERATORS (version 2)
- To: Jon L White <email@example.com>
- Subject: Issue: HASH-TABLE-PACKAGE-GENERATORS (version 2)
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Fri, 7 Oct 88 21:50 EDT
- Cc: firstname.lastname@example.org
- In-reply-to: <8810072337.AA02095@bhopal>
Date: Fri, 7 Oct 88 16:37:53 PDT
From: Jon L White <email@example.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.
I haven't gotten myself up to date on the new exception terminology yet,
not being on the editorial committee. I think you don't think "is an error"
means the same thing that I think it means, but "unspecified" is okay with me.
I hope the new exception terminology doesn't use words with legal force
such as "guarantee."
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.
That might be a good idea, then :INTERNAL and :EXTERNAL and :INHERITED
can be specified independently. I haven't thought about it for more
than five seconds.