Memorial Day Ballot

[Walter van Roggen <Walter.VanRoggen@CMU-CS-A> (C410WV50)]

[1] ok
[2] ok
[3] yes. GET-INTERNAL-TIME and GET-REAL-TIME might return different
    values even for a personal machine. Return values should be in
    units of INTERNAL-TIME-UNITS-PER-SECOND. Some implementations
    might want to return multiple-values to separate out GC time.
[4] ok
[5] yes
[6] maybe: why not in all lambda lists?
[7] no and yes. I don't know why people have been talking about using
    CATCH-ALL to handle errors in particular. It seems the natural way
    to detect, and perhaps intercept, throws of any kind, particularly
    unknown ones. Say you have a large program with many different
    "top-levels", and corresponding different interrupt characters (like
    ^G). At some level, you might want to restrict which levels one might
    pop up to. You need to know what the throw tag is. But given both
    UNWIND-PROTECT and CATCH-ALL, UNWIND-ALL doesn't seem so useful.
    Also, is CATCH-ALL so much harder to implement than UNWIND-PROTECT?
[8] no. I presume you don't really mean that DEFMACRO is used by users
    to define special forms. Lisp implementors' use of DEFMACRO for special
    forms doesn't have to be nice looking. Furthermore, list destructuring
    in parameter lists is visually confusing and conceptually confusing
    because of the difference with normal lambda lists. I often find
    it convenient to convert from DEFUN to DEFMACRO.
    On the other hand, destructuring can be very convenient. This is a
    separate issue, but I would like to see a more general destructuring
    LET as a facility in its own right, with which it would be easy to
    implement destructuring defmacros. This would apply not only to lists,
    but to structures also. One annoyance I've noticed with lots of
    defstructs is that it's tedious to have to write all those (foo-slot x)
    forms. It would be nice to have something equivalent to the PASCAL WITH.
    SETF would have to be smarter, though.
[9] ok
[10] ok. It's good to get rid of SGVREF.
    Looking at the array chapter I thought there was no way to reference
    a non-simple vector while observing the fill-pointer, since AREF doesn't
    and things like CHAR are defined in terms of AREF. But I presume ELT
    does; there need to be cross-references both ways. So implementations
    have to duplicate the array referencing mechanism for vectors (e.g.,
    for declared strings). It would also be good to state for THE, examples
    like (THE (VECTOR CHARACTER n) (THE (SIMPLE-ARRAY STRING-CHAR n) foo)).
    I presume also that MAKE-SIMPLE-VECTOR no longer takes an :ELEMENT-TYPE
    keyword, and therefore VECTOR changes.
    My main complaint is that we are encouraging a proliferation of accessing
    types. Much as there is no VREF, let's get rid of CHAR and BIT. Since
    we think there will be much use of SVREF, keep SCHAR and SBIT. Finally,
    we should consider renaming those three without the "S".
[11] yes
[12] ok. But can't DEFSTRUCT always assume the first slot is used if named?
[13] yes, *READ-BASE*. How about changing *PRINT-RADIX* to mean "whenever
    *BASE* isn't 10." Perhaps also then change its default value to T.
[14] ok with keywords
[15] yes
[16] I don't even want to think about it.
[17] yes
[18] ok. why can't package prefixes be treated exactly like symbols,
    except that they aren't interned? #\: terminates unless quoted.
    Package names are backslashified or ||'d on printing. So |aBC|:|Foo|
    or |:|:|:| or |temp|#:G0001 
[19] ok
[20] no. TIME, DESCRIBE, APROPOS, and ROOM are all similar; they all are
    most commonly used interactively at top-level. I suggest an optional
    keyword arg that specifies which stream to output to, just like
    FORMAT. Since these functions will be so implementation-dependent,
    we shouldn't restrict what they do nor what they return.
    As a general rule, 0 values sounds reasonable when just printing.
    Implementations should be able to add their own keyword args, and
    return whatever lists (or ?) appropriate. For APROPOS, you might be
    interested in defined symbols only; APROPOS-LIST is too specific
    (and it's easy to write anyway). APROPOS, might want to capitalize
    the string first, also.
[21] no, you may want to check for symbols in particular packages.

			---Walter