Memorial Day Ballot

[BENSON at SPA-NIMBUS]

1. Yes.
2. Yes.
3. This needs some better justification.  It doesn't appear to be useful
   in portable code.  Are the things returned by these functions
   integers?
4. Yes.
5. Yes.  Be very careful in explaining this in the manual; it is tricky.
6. No.  NIL already has too much attached to it.  A decent compiler will
   detect variables which are set but not used.  It's not important
   enough to add another "keyword" usage to NIL.
7. Yes.
8. Yes, with a style hint in the manual that mixing & keywords and
   destructuring is poor form.  I would like to see a way to use
   DEFMACRO-style list groveling (both kinds) in places other than
   DEFMACRO.  I recently wanted to use it in an assembler, for defining
   macros.  DLET and/or DESETQ would be very useful.
9. Yes.
10. Yes.
11. Yes.
12. Yes, approximately.  Remember, the NAME of the vector is the TYPE of
    the DEFSTRUCT (not to be confused with the element type), the thing
    returned by TYPE-OF.  :NAMED is really the wrong name for this
    option.  This would in fact be the only place where objects of a new
    user-defined type can be created.  Perhaps it should be called
    :TYPE-OF, although that might cause some confusion with
    :ELEMENT-TYPE.
13. Yes, call it *READ-BASE*.
14. No.  I don't think the user needs to be concerned with whether a
    call to READ is at top level or not, since READ has to use a
    special variable to keep track of its state.  READ can look at that
    variable to see if it is being called recursively; if so, then it
    would do SUB-READ.  This global state will still be needed, even if
    SUB-READ is defined.  The only way to avoid it would be to add a third
    READER-STATE argument to read macros, which would have to be passed
    to recursive READs or SUB-READs.  Notice that the example given
    under READ-DELIMITED-LIST now has no way of knowing whether to call
    READ-DELIMITED-LIST or SUB-READ-DELIMITED-LIST.  Rather than adding
    this hair, let's leave it up to the system to tell whether it's
    being called recursively.  A side issue: are dots allowed in
    READ-DELIMITED-LIST?  I would say no; the manual should specify
    either way.
15. Yes.
16. Yes.
17. Yes.
18. Yes.  I can't understand why anyone would think it was hard in the
    first place.
19. Yes.
20. Yes, but make it T instead. (NIL is so negative!)
21. Put them in the GLOBAL (excuse me, LISP) package, instead of
    KEYWORD.  Otherwise, users will be typing #+:FOO.  Actually, there's
    no need to specify.  One ought to be able to push any symbol onto
    *FEATURES*.  The object after #+ and #- should be read just like any
    other.  Remember, it can be a list, too.