[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Memorial Day Ballot
- To: Fahlman@cmu-cs-c
- Subject: Memorial Day Ballot
- From: Walter van Roggen <Walter.VanRoggen@CMU-CS-A> (C410WV50)
- Date: Wed, 01 Jun 1983 19:46:00 -0000
- Cc: common-lisp@su-ai
 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.
 maybe: why not in all lambda lists?
 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?
 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.
 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".
 ok. But can't DEFSTRUCT always assume the first slot is used if named?
 yes, *READ-BASE*. How about changing *PRINT-RADIX* to mean "whenever
*BASE* isn't 10." Perhaps also then change its default value to T.
 ok with keywords
 I don't even want to think about it.
 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
 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.
 no, you may want to check for symbols in particular packages.