ballot issues

[Scott E. Fahlman <Fahlman@CMU-CS-C>]

Guy,

I like the spirit of your proposal to distinguish internal and top-level
calls to READ through the use of flags passed in through EOF-ERRORP, but
there are a couple of problems.  First, EOF-ERRORP is no longer a "p" --
there are three values, and the action comes from two non-null flags.
Second, EOF-ERRORP is no longer just about errors.  As you point out,
top-levelness controls a couple of other issues as well.  So I think
that leaving the name as it is would be very confusing.

What about the following:

Leave all the read forms just as is, but add a new optional argument
RECURSIVE-P at the end.  (This goes on all the read functions that
currently have EOF-ERRORP and EOF-VALUE.)  If non-null, this indicates a
recursive (non-"top-level") call.  In such cases, the function's
EOF-ERRORP and EOF-VALUE are ignored and should be NIL.  The top-level
call's arguments determine the EOF action.

This makes it possible to get the desired effect without new functions
and without going to keywords in all of these functions.  As a general
rule, a function with this many flags would want to be converted to
keywords, but the casual user would almost always take the default for
the last arg, or even the last three args.

As for your vertical bar proposal, I don't like it much.  I see no
reason for package names to sprout all the syntactic hair that symbols
have.  It seems to me that the reader gobbles down the characters
forming a token, treats any unslashed : or #: as terminating the token,
and if these particular terminators are seen, it takes the token-so-far
and treats it (verbatim) as a package-name string rather than doing the
slashified upcasing and treating it as a symbol.  If the reader wants to
do the symbol-upcasing as it reads in the characters, this means that it
has to stash away the original characters as well -- not too bad.

Just to avoid any confusion, I would forbid package names to contain |,
\, : or any whitespace.  If you see any of those, and then the : or #:
terminator, signal an error.  Why go to the trouble of providing the
user with a way to get these into package names, just so that horribly
confusing situations can be created?

The alternative would be to treat case identically in all parts of a
qualified symbol: upcase things not slashified and do a case-sensitive
match.  Then |'s around the whole thing or around either half would be
OK.  But since there is no tradition of using package names for
pseudo-strings and other randomness, I would prefer to keep them free of
this machinery.

-- Scott