[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Results of the 21 August 1982 Common LISP Meeting
- To: common-lisp at SU-AI
- Subject: Results of the 21 August 1982 Common LISP Meeting
- From: STEELE at CMU-20C
- Date: Mon, 23 Aug 1982 20:12:00 -0000
The Common LISP Meeting started at 9:45 AM on 21 August 1982.
The following people attended the meeting: Guy Steele, Walter van Roggen,
Gary Brown, Bill van Melle, David Dill, Richard Greenblatt, Glenn Burke,
Kent Pitman, Dan Weinreb, David Moon, Howard Cannon, Gary Brooks, Dave Dyer,
Scott Fahlman, Jim Large, Skef Wholey, Jon L White, Rodney Brooks,
Dick Gabriel, John McCarthy, and Bill Scherlis.
One hundred and fifty agenda items had been previously prepared.
These were discussed and for the most part resolved. Another eleven
items were brought up at the end of the meeting. The meeting was
adjourned at 6:00 PM.
Following is a copy of the prepared agenda, annotated with the results
of the meeting, and the additional topics and their results.
--Guy
AGENDA FOR COMMON LISP MEETING
21 AUGUST 1982
ANNOTATED WITH THE RESULTS OF THE MEETING
1. What objects should be self-evaluating? In particular,
should a bit-vector self-evaluate, and should an (ARRAY (MOD
4)) self-evaluate? Suggestion: everything should
self-evaluate except for symbols, structures, and all objects
other than numbers that have pointer components.
GLS will make a proposal. Symbols and lists do not
self-evaluate, numbers and strings do. Odd objects
should be an error.
2. Should something be done about the fact that BYTE specifiers
use a start-count (actually, a count-start) convention, while
the rest of the language uses a start-end convention?
No. This will be left as is.
3. Shall keywords be self-evaluating, and kept in a separate
package? The motivation for the latter is that they will
always be printed with a colon; for the former, that keyword
argument names need not be written with a quote and a colon,
but only a colon, which makes the call syntax consistent with
that for macros.
Keywords are symbols, but are kept in their own
package. SYMEVAL of a keyword works, and returns
that same keyword. INTERN must arrange for the value
of a keyword to be that keyword when that keyword is
interned in the keyword package.
4. Should the third (tolerance) argument to MOD and REMAINDER be
eliminated?
Yes.
5. Should all tolerance arguments be eliminated? This would
include elimination of FUZZY=.
Yes.
6. Should arrays of identical size whose elements match be
EQUALP, even if their element storage format is different?
(Example: can a bit-vector be EQUALP to an array of pointers
that happens to contain only the integers 0 and 1?)
Yes, EQUALP descends into arrays and does this. On
the other hand, EQUAL descends essentially only into
things that self-evaluate. This will be clarified
explicitly.
7. While EQL is the best default test for the sequence
functions, is it better to make MEMBER, DELETE, and ASSOC
continue to use EQUAL for backward compatibility? Perhaps
alternative names for the general, EQL-defaulting case can be
found?
EQL will be used for everything. Consistency is more
important than compatibility here.
8. Scope and extent of GO and RETURN. Can one GO out from an
argument being evaluated? Can a GO break up special variable
bindings? Can a GO break up a CATCH? Does GO work despite
funargs?
Yes to all of these. The tags established by a PROG
have dynamic extent and lexical scope; the same goes
for RETURN points. Compilers are expected to
distinguish the obvious easy cases from the hard
ones.
9. Forbid multi-dimensional arrays to have fill pointers?
Yes.
10. Should updating functions be eliminated in the white pages in
favor of consistent use of SETF?
Keep RPLACA, RPLACD, and SETQ out of respect for
tradition. All the others can go. This solves the
controversy surrounding PUTPROP, as well as the
difficulty with ASET and VSET differing in their
argument order.
11. Is the use of * in type specifiers satisfactory to indicate
missing elements? (RMS suggested use of NIL, but there is a
problem: (ARRAY INTEGER ()) means a 0-dimensional array of
integers, while (ARRAY INTEGER *) means any array of
integers.)
Yes.
12. Should &KEY be allowed in DEFMACRO?
Yes.
13. Should complex numbers be required of every COMMON LISP
implementation?
There was discussion to the effect that the precise
definitions of the branch cuts is still in a sate of
flux. There are minor differences between the APL
proposal and the proposal by Kahan that encompasses
proposed IEEE floating-point format. Keep complex
numbers in the manual, with a note that the precise
definitions are subject to change and are expected to
be tied down before January 1, 1984, at which time
they will be required of all COMMON LISP
implementations.
14. Is the scheme outlined for DEFSTRUCT, wherein constructor
macros can actually be functions because of a conventional
use of keywords, acceptable?
Yes. Also note that the various functions may be
automatically declared INLINE at the discretion of
the implementation.
15. Why should the DEFSTRUCT default type be anything in
particular? Let it be whatever is implementationally best,
and don't mention it.
Simply note that TYPEP of two arguments must work
properly on structures in the default case. For
example, after SHIP is defined, and X is a ship, then
(TYPEP X 'SHIP) must be true, and (TYPEP X 'ARRAY)
may or may not be true.
16. Proposed to flush DEFSTRUCT alterant macros, advising the
user always to use SETF.
Yes. However, there must also be a way to provide
one's own SETF methods via DEFSETF.
17. Can we standardize on keywords always being used as
name-value pairs? The worst current deviants are
WITH-OPEN-FILE and DEFSTRUCT options.
Yes. The Lisp Machine LISP group will make a
proposal soon for OPEN, WITH-OPEN-FILE, and
DEFSTRUCT.
18. What types may/must be supertypes of others? What types may
overlap, and which must be mutually exclusive? An explicit
type tree is needed. Examples: can bignums be vectors? Are
BIT-VECTOR and (ARRAY (MOD 2)) identical, disjoint, or
overlapping?
Let ``>'' means ``is a supertype of''. Let ``#''
mean n-ary ``is disjoint from''; ``A#B#C#D'' means
that A, B, C, and D are pairwise disjoint. Let ``#''
have higher precedence that ``>'', so that
``Z>A#B#C'' means that A, B, and C are pairwise
disjoint subtypes of Z. Then:
t > common > cons # symbol # array # number
# character
number > rational # float # complex
rational > integer # ratio
integer > fixnum # bignum
float > short-float
float > single-float
float > double-float
float > long-float
character > string-char
array > quickarray/vector
The four subtypes of FLOAT are such that any pair are
either identical or disjoint. The type COMMON
encompasses all data types defined in the white
pages; perhaps its definition should be made
carefully so that, for example, an implementation can
introduce new kinds of numbers without putting them
under COMMON. So, perhaps COMMON should instead be
defined to be
COMMON > cons # symbol # array # rational
# short-float # single-float # double-float
# long-float # standard-char # hash-table
# readtable # package # pathname # stream
Anyway, you get the idea.
19. Are there type names (for Table 4-1) such as RATIONAL,
FUNCTION, STRUCTURE, PACKAGE, HASH-TABLE, READTABLE,
PATHNAME, and so on?
Yes, except for STRUCTURE. Also, eliminate
STRUCTUREP.
20. How can one ask, ``Is this an array capable of holding
short-floats?''?
Invent a function that extracts this information from
an array.
21. Rename DEFCONST to avoid conflict with Lisp Machine LISP. (I
think the November meeting actually voted for DEFVALUE, but I
forgot to edit it in. --GLS) DEFCONSTANT would do. What
Lisp Machine LISP calls DEFCONST should go into COMMON LISP
as DEFPARAMETER or something.
Rename what the COMMON LISP manual now calls DEFCONST
to be DEFCONSTANT. Introduce a new construct
DEFPARAMETER to do what Lisp Machine LISP DEFCONST
does. Retain DEFVAR with that name.
22. Should one allow both required and optional keyword
parameters?
No; have only optional keyword parameters. However,
permit the use of ordinary &OPTIONAL parameters and
&KEY parameters together, withg the former preceding
the latter.
23. Should &REST be allowed with &KEY after all? How about
&ALLOW-OTHER-KEYS? (It turns out these features are useful
for gathering up all your keyword arguments and letting some
sub-function inherit them.)
Yes. Also, state that if a key is duplicated as an
argument the leftmost one prevails and the others are
ignored (a GET-like model).
24. Should EQUAL be allowed to descend into arrays? Vectors?
No and yes. See issue 6.
25. Proposed not to attempt to standardize on a package system
for COMMON LISP at this time. Reserve the colon character
for the purpose, and explain a bit about how to use it, but
don't tie down all package details.
Agreed. State that there are packages, and that they
are used as arguments to certain functions such as
INTERN. State explicitly that inheritance
properties, if any, are undefined. State that all
uses of colon except for keyword syntax are reserved,
but mention the general intent of the notation
FOO:BAR.
26. Various problems with pathnames: generic pathnames,
interning, :UNSPECIFIC, logical pathnames.
GLS and SEF will propose a very stripped-down subset
of what is presently in the COMMON LISP manual. RG
and Symbolics may also make proposals.
27. What is the maximum array rank? Is it implementation-
dependent? If so, what is the minimum maximum?
The minimum maximum shall be 63.
28. What special forms may be documented to be macros, in order
to minimize the number of special forms?
There is agreement so to minimize the number of
special forms. GLS will make a proposal.
29. Should a way be provided for the user to define functional
streams? If not, should DEFSELECT and SELECT-expressions
remain in the language?
COMMON LISP will, for now, not specify a way to
create functional streams. DEFSELECT and select-
expressions shall be deleted. HIC will propose
within two weeks a simplified instance system similar
to the ones in MACLISP and NIL intended to support
object-oriented programming while remaining neutral
with respect to inheritance issues, to encourage
experimentation.
30. Are COMMON LISP arrays stored in row-major order? If not,
what is the interaction with displaced arrays?
Row-major order shall be used.
31. It is silly to have two of every I/O function, one for
integers and one for characters. Flush one set (TYI, TYO,
TYIPEEK, ...) and leave the other (INCH, OUCH, INCHPEEK,
...).
Agreed to eliminate the TYI series and to rename the
others to eliminate the ``cute'' names. The new
names will be:
Old name New name
inch read-char
ouch write-char
in read-byte
out write-byte
inchpeek peek-char
(none) peek-byte
32. Should some value be reserved for eof-value to mean the same
as not supplying any?
All occurrences of an eof-value parameter shall be
replaced by two &OPTIONAL parameters eof-errorp
(defaulting to true) and eof-value (defaulting to
NIL, and meaningful only if eof-errorp is false).
33. FORCE-OUTPUT should not wait, but just initiate I/O. There
should be a FINISH-OUTPUT (which implies FORCE-OUTPUT) that
does wait.
Yes.
34. Should all vectors have fill pointers? If so, should nearly
all functions consistently use the active-length?
An array may or may not have a fill pointer. Vectors
(``quickarrays'') shall be defined as a subset of
arrays in such a way that they have no fill pointers.
All functions that use arrays will use the fill
pointer to bounds-check and limit access, except AREF
(and SETF thereof). Array slots beyond the fill
pointer are still alive and may not be gratuitously
garbage-collected or otherwise destroyed.
35. Should HAULONG be changed from its current definition
ceiling(log (abs(integer)+1)) to the one proposed by EAK, namely
2
if integer<0 then ceiling(log (-integer)) else ceiling(log (integer+1))
2 2
? With either definition, a non-negative integer n can be
represented in an unsigned byte of (HAULONG n) bits. With
EAK's definition, it is also true that an integer n (positive
or negative) can be represented in a signed byte of (+ (HAULONG N) 1)
bits.
Adopt the EAK definition under the name integer-
length.
36. Should HAULONG and HAIPART be given more reasonable names?
Eliminate both HAULONG and HAIPART. Put
compatibility notes under INTEGER-LENGTH and LDB.
37. How should the IEEE proposed floating-point standard be
accommodated? In particular, what about the trichotomy of <,
=, and >, and how might underflow/infinity/NAN values be
handled?
Agreed that COMMON LISP must permit the use of IEEE
proposed floating-point format and operations.
Statements about such matters as trichotomy must be
carefully worded. Suggestions will be solicited from
RJF concerning such accommodation.
38. If PROGV has more variables than values, proposed that the
extra variables be initialized to ``unbound'' rather than
NIL. This is already done in MACLISP.
Yes. (It was suggested that a similar thing be done
with LET and PROG: (LET ((A ()) B) ...) makes A bound
to NIL, but B unbound (that is, an error to refer to
it before it is set). My notes are unclear as to
whether this was agreed to.)
39. Shall EXCHF be generalized to take n locations and
left-rotate them? Shall SWAPF be correspondingly generalized
to take N locations and a value and left-shift them? (Suzuki
indicates that these are useful primitives and lead to more
understandable code in some cases.)
PSETF, a parallel SETF shall be introduced; so shall
a multiple-pair sequential SETF. GLS is to propose
Suzuki-type primitives with better names that EXCHF
and SWAPF.
40. Shall TYPEP of one argument be renamed to something else, or
eliminated?
Rename it to be TYPE-OF. Note that while the results
are implementation-dependent, they can be used in
portable code, for example, by handing the result,
without further examination, to MAP or CONCATENATE.
41. In pathnames, shall names and types also be allowed to be
structured?
Deferred. See issue 26.
42. Should the interpreter be required or encouraged to check
type declarations? At binding time? At SETQ time?
Encouraged but not required. That is, violation of
type declarations ``is an error'' but does not
``signal an error''.
43. How should complex numbers be notated? With #C syntax?
Using an infix J? In the form x+yI? Examples: #C(0 1),
#C(3.5E-7 -15/3); 0J1, 3.5E-7J-15/3; 1I, 3.5E-7-15/3I.
Retain #C syntax.
44. How about using :OPTIONAL instead of &OPTIONAL, and so on?
No; retain &OPTIONAL.
45. Rename CEIL and TRUNC to CEILING and TRUNCATE?
Yes.
46. Should minimum precision and exponent range be specified for
each of the floating-point formats?
Yes, but the table in the COMMON LISP manual does not
accommodate Lisp Machine LISP short-floats and S-1
LISP short-floats. GLS will fix this.
47. Should it be specified that if an implementation provides
IEEE proposed floating-point format, that the single and
double formats shall in fact be the IEEE single and double
formats?
Yes; however, carefully word it, because the IEEE
proposed standard permits implementation of single-
precision format without implementing double-
precision format.
48. Revise the format for vectors, structures, and so on, all to
use #(...) syntax. Boxed vectors can be #(V ...), arrays can
be #(ARRAY ...), complex numbers #(C 0 1), and structures
#(SHIP ...). RMS says this will be easier for EMACS-like
editors to parse.
No; this was judged harder for people to read. Let
the editors be fixed.
49. Are variables truly to be lexically, rather than locally,
scoped?
Yes.
50. Are FLET, LABELS, amd MACROLET worth keeping?
Yes.
51. Rename multiple-value constructs to all have the same prefix,
either MV, MV-, or MULTIPLE-VALUE-, consistently.
The prefix ``MULTIPLE-VALUE-'' will be used
consistently.
52. Proposed to keep the names GET and REMPROP, and rename
PUTPROP to PUT (revising argument order), rather than current
names GETPR, PUTPR, and REMPR.
The names GET and REMPROP will be used. PUTPROP is
eliminated in favor of SETF of GET.
53. The definition of ADJUST-ARRAY-SIZE on multi-dimensional
arrays seems to follow from implementation considerations,
rather than because it is useful to a user. ARRAY-GROW is
more user-useful. Flush ADJUST-ARRAY-SIZE?
MOON has a proposal that a function of this kind
should take keywords much as MAKE-ARRAY does, but
also take an ``old array'' that is made to conform to
the new specifications. GLS will make a concrete
proposal.
54. Should things like CHARPOS and LINENUM be built in?
No, eliminate them.
55. Flush MAKE-IO-STREAM and MAKE-ECHO-STREAM; they are too
simplistic and can't really handle the tight I/O coupling.
Keep them, but find a better name for MAKE-IO-STREAM.
They may be useful in simple cases.
56. Should OUT be able to output other than positive integers?
What about ways of putting other objects, such as
floating-point numbers, out to binary files?
No; it ``is an error'' for the argument to OUT (now
named WRITE-BYTE) to be other than a positive integer
that can fit into bytes of the size suitable to the
stream. GLS will make a proposal for other
primitives to write floating-point numbers and other
objects to binary files.
57. Flush FQUERY, on the grounds that it is too hairy for simple
things and not hairy enough for a general menu interface, for
example?
Yes, flush it.
58. Should the INTERLISP SATISFIES type specifier be introduced?
If so, perhaps it should take a function, not a form, as
there are problems with when to evaluate the form.
Yes.
59. What about the proposed safety feature to prevent macros and
special forms from being redefined as functions (signal a
correctable error)?
Eliminate this ``feature''.
60. Proposed: (RESTART [block-name)] is essentially a jump to the
top of the named block, a somewhat smaller sledgehammer than
a full PROG with a GO.
This appears to be a good idea; however, a more
detailed proposal is required to clarify such points
as whether a RESTART within a PROG unbinds and
rebinds the variables.
61. Proposed: (CYCLE . body) is like a BLOCK with no name and an
implicit RESTART at the end. This is a new name for
DO-FOREVER. Certain loops that are clumsy to do with DO are
lots easier with this, without a full PROG.
Yes, but call it LOOP, as this is a special case of
the forthcoming LOOP proposal.
62. If a GO or RETURN is permitted to pass out of a CATCH-ALL or
UNWIND-ALL, what arguments does the catcher function receive?
Eliminate the current CATCH-ALL and UNWIND-ALL.
Introduce a new function CATCH-ALL that is just like
CATCH but takes no tag and catches any attempt
whatsoever to unwind. The return values for a GO and
other odd cases must be defined.
63. Is the IGNORE declaration acceptable?
Yes.
64. Is the OPTIMIZE declaration acceptable?
It is a good idea but inadequate as currently
defined. SEF will make a new proposal.
65. How should symbols that belong to no package be printed? A
suggestion: ``#:pname''. The reader should read this as a
non-uniquized symbol. If the same gensym appears several
times in the same printed expression, that can be handled by
the #= and ## syntax.
Reserve this syntax pending a proper package
proposal.
66. Proposed to retract GCD of complex rationals, and restrict
GCD to integer arguments.
Yes.
67. Is PUSHNEW as a predicate useful, or should the simpler
definition be adopted?
Use the simpler definition.
68. PUSHNEW should take the :TEST keyword.
Yes.
69. Should the :TEST-NOT keyword be flushed for ADJOIN, UNION,
INTERSECTION, SETDIFFERENCE, and SET-EXCLUSIVE-OR?
Yes.
70. What about pervasive package syntax? Is ``SI:(A B C)''
legal?
Yes. Actually, this syntax is reserved for whatever
the package system looks like.
71. For circular list syntax, should it be required that a
reference #n# not occur before the #n= that defines it?
Yes. This restriction may be relaxed in the future.
72. Rename the type STRING-CHAR to be STRING-CHARACTER.
No.
73. Rename the type RANDOM; that is an abuse of the word RANDOM.
Suyggestion: INTERNAL. It is not necessarily used at all; it
is just a catch-all under which to put odd implementation-
dependent things such as pointers into the stack or absolute
memory.
Eliminate the type RANDOM. Introduce the new type
COMMON (see issue 18). Mention that there may be
implementation-dependent data types.
74. There needs to be a kind of BLOCK to which RETURN is
oblivious. It is primarily useful for macro definitions, so
it need not have a simple name. How about INVISIBLE-BLOCK?
GLS and SEF will make a better proposal.
75. Proposed to flush DEFMACRO-CHECK-ARGS: the macro should
always perform this error check.
Yes. At least, whether the error check is done
should be left to the implementation just as
wrong-number-of-arguments-to-a-function is.
76. Proposed to flush DEFMACRO-MAYBE-DISPLACE and macro-
expansion-hook; the former is useless and the latter is not
general enough.
Deferred.
77. Proposed to make MACROEXPAND-1 be the sole standard hook for
getting at a macro expanding function; this means MACRO-P
should not return the macro function. This allows the
implementation to provide whatever memoizing scheme
appropriate.
Interesting idea; deferred. MOON and SEF will make
proposals on this issue and the previous one.
78. Need some kind of declaration to locally shadow a globally
pervasive SPECIAL declaration.
The pervasiveness of such declarations must be
clarified. Sample code for EVAL should appear in the
COMMON LISP manual. GLS will propose such code.
79. Functions that take two sequences should not accept :START
and :END, only :START1 and friends, to minimize confusion.
Yes.
80. All built-in MAKE- functions should take keywords.
Yes.
81. There should be only one function for creating hash tables,
and it should take a :TEST keyword.
Yes, but the value for this keyword is restricted to
a small set of possibilities.
82. One-argument FLOAT should either always return a single-
float, or use the format specified by read-default-float-
format.
One-argument FLOAT will always return a SINGLE-FLOAT.
83. Proposed to make the second argument (the divisor) to MOD and
REMAINDER required, not optional.
Accepted. The one-argument case is obtained by
providing 1 as a second argument, which is much
clearer.
84. If RANDOM can take two arguments, the first effectively
optional and the second required, why cannot LOG do the same?
How about EXP, too?
The second (optional) argument to RANDOM shall be
eliminated.
85. TRUENAME of a string should look in the file system, not just
return the string.
Yes.
86. WITH-OPEN-FILE should not be specified to ask the user; if
anything, it should merely specify that an error is
signalled.
Yes.
87. The keyword arguments to LOAD should be fixed up in a way to
be proposed by MOON.
MOON will make a specific proposal.
88. Can DEFUN be used to define properties? How about more
general function-specs, as in Lisp Machine LISP?
Function-specs are tentatively accepted pending a
specific proposal.
89. Let declarations and documentation-strings occur in any order
in a DEFUN and similar forms.
Yes.
90. Provide a functional interface for accessing documentation
strings, rather than mentioning the DOCUMENTATION property.
Deferred for discussion by network mail.
91. Clarify the status of the DOLIST/DOTIMES variable when the
result-form is executed. Proposed: for DOLIST, variable is
bound and has NIL as its value; for DOTIMES, variable is
bound and has as value the value of the countform.
GLS will make a proposal. Feelings were not strong
except that the issue must be tied down.
92. Is VALUES a function? Or should it, like PROGN, really be
regarded as a special form?
It is a function.
93. Should LOCALLY be retained, or should one simply write (LET
() ...)?
Retain LOCALLY.
94. Extend THE to handle multiple values? One way is to provide
a limited type specifier so that one may write
(mvcall #'+ (the (values integer integer) (floor x y)))
Yes.
95. Should compiler warnings of unrecognized declarations be
required or merely recommended? Perhaps required as the
default, but a switch may be provided?
Agrred that it is probably a good idea to require it,
provided that a declaration may be made to indicate
that a particular declaration is legitimate. GLS
will make a specific proposal.
96. There should be a kind of FLOAT that accepts a type specifier
instead of an example of that type. (But the kind that takes
an example is useful too.)
The function TO should be renamed COERCE, take a type
specifier as second argument, and be extended to
other cases such as floats.
97. Have a function that somehow extracts the fraction from a
floating-point number and returns it as an integer.
Proposed: FLOAT-FRACTION-INTEGER takes a floating-point
number x and returns two integer values; the second is the
precision p of the representation, and the first is a value j
such that (= j (SCALE-FLOAT (FLOAT-FRACTION x) p)). Or
perhaps this should be two separate functions.
MOON will make a proposal. The term fraction should
be replaced where appropriate by significand, as
there can be confusion with integer-part/fractional-
part.
98. Flush MASK-FIELD and DEPOSIT-FIELD?
No, keep them.
99. Is the proposed definition of backquote acceptable?
The printed copies of the COMMON LISP manual did not
make backquotes visible. GLS will send the proposal
out by network mail for discussion.
100. STRING-CHARP should be true of <space>.
Yes.
101. Rename GRAPHICP and ALPHAP to GRAPHIC-CHARP and ALPHA-CHARP.
Yes.
102. Introduce CHAR<=, CHAR>=, and CHAR/=, and let the character
comparators take multiple arguments as for the numeric
comparators. (But note that (char<= #\A X #\Z) doesn't
guarantee that X is a letter.)
Yes.
103. In STRING-CAPITALIZE, should digits count as word-
constituents, even though they don't have case?
Yes. (This is as in EMACS.)
104. Do not have both DIGIT-CHARP and DIGIT-WEIGHT.
Flush DIGIT-CHARP; let DIGIT-WEIGHT return NIL for a
non-digit.
105. Introduce a function MAKE-SEQUENCE taking a type, length, and
a keyword :INITIAL-VALUE.
Yes.
106. CATENATE or CONCATENATE? The OED says they are semantically
identical.
CONCATENATE it is.
107. Be sure to add REMOVE-DUPLICATES and DELETE-DUPLICATES.
Yes.
108. Suggest letting NIL as a return type to MAP mean return no
value, to get a MAPC-like effect.
Yes.
109. Flush :FROM-END keyword for the COUNT function?
No, keep it for consistency, even though it is
useless.
110. What should be done about SUBST and SUBLIS?
Have four functions SUBST, NSUBST, SUBLIS, and
NSUBLIS. All take the usual applicable sequence
keywords, particularly :TEST. They do operate on
cdrs. The non-destructive versions do maximal
sharing; (SUBST () () X) will no longer be a good way
to copy X. Give a sample definition of SUBST in the
COMMON LISP manual.
111. Flush the restriction that the result of SXHASH be
non-negative?
Keep the restriction.
112. What is the interaction of ARRAY-GROW and displaced arrays?
This does the ``obvious right thing''. Run-time
access checks may be required if the displaced-to
array is altered.
113. Add WITH-INPUT-FROM-STRING and WITH-OUTPUT-TO-STRING?
Yes, and note that the created stream has only
dynamic extent.
114. Should CLOSE take a simple flag or a keyword argument :ABORT,
defaulting to NIL?
A keyword argument: (CLOSE :ABORT T).
115. Rename PRIN1STRING to be PRIN1-TO-STRING.
Yes.
116. Rename FILEPOS to FILE-POSITION.
Yes.
117. Rename COMFILE to COMPILE-FILE?
Yes.
118. Reconsider the problem of getting at file attributes, such as
author.
A single function GET-FILE-INFO should take a stream
and a keyword indicating what is desired.
119. Add COMPILER-LET?
Yes.
120. Rename the type SUBR to be COMPILED-FUNCTION.
Yes. Also rename SUBRP.
121. Note that implementations may provide other &-keywords for
lambda lists (these won't be portable, however).
Yes. Document the variable LAMBDA-LIST-KEYWORDS.
122. Rename the ONEOF type specifier to be MEMBER.
Yes, in principle; tie this to the outcome of MEMBER.
(This came out all right (issue 7), so I take this to
be an unqualified yes.)
123. The syntax of ratios should be clarified. Proposal:
ratio ::= [sign] {digit}+ / {digit}+
Yes.
124. Proposed to call the page-separator character #\PAGE instead
of #\FORM.
Yes.
125. Proposed that all COPY functions should be spelled COPY-.
Yes, except if a function is named just ``COPY'',
don't call it ``COPY-''!
126. Proposed: a new FORMAT directive ~$, as in MACLISP, for
better control over floating-point number printout.
Yes.
127. Proposed: a new FORMAT directive ~/.../, where ``...'' is a
picture, for pictorial representation of integer and
floating-point printout, as in PL/I and COBOL. Details are
to be determined, but as possible examples:
Value Picture Result
65.67 ~/$$,$$$,$$9.V99 CR/ " $65.67 "
0.0 ~/$$,$$$,$$9.V99 CR/ " $0.00 "
-65432.01 ~/$$,$$$,$$9.V99 CR/ " $65,432.01 CR"
-65432.01 ~/$*,***,**9.V99 CR/ "$***65,432.01 CR"
-65432.01 ~/$Z,ZZZ,ZZ9.V99 CR/ "$ 65,432.01 CR"
6.5 ~/S9.V99999ES99/ "+6.50000E+00"
.0067 ~/S9.V99999ES99/ "+6.70000E-03"
456 ~/ZZZZZ9/ " 456"
456 ~/999999/ "000456/
Some study of existing picture formats would be necessary.
If it's done right, EDIT instructions on machines such as the
IBM 370 and DEC VAX might be applicable.
General sympathy for this idea, but GLS must make a
concrete full proposal.
128. Proposed: a new FORMAT directive ~U that prints
floating-point numbers in exponential form, with the exponent
a multiple of three, and also outputs a standard metric
prefix such as ``kilo'' to match.
Yes, in principle; a complete proposal will be
discussed by network mail.
129. Proposed: a new FORMAT directive ~(...~) for case conversion.
No flags means force to lower case; colon capitalizes all
words; atsign capitalizes just the first letter, lower-casing
all others; colon and atsign forces to upper case. This is
useful for such things as
(defun foo (n) (format () "~@(~R~) error~:P detected" n))
(foo 0) -> "Zero errors detected."
(foo 1) -> "One errors detected."
(foo 23) -> "Twenty-three errors detected."
Yes, but better characters than ``('' and ``)''
should be found. GLS will make a proposal.
130. Proposed: in FORMAT, eliminate ~[ from COMMON LISP, but
retain the colon and atsign versions.
No, keep it.
131. Proposed: new FORMAT directive ~? to mean that an argument is
to be interpreted as a control string, as if inserted at that
point. This is simpler than remembering to use ~1{~:}.
Yes. Look for a better character.
132. Proposed: FORMAT directives to perform FORCE-OUTPUT and
CLEAR-OUTPUT.
No! Fix the manual under FORCE-OUTPUT and
CLEAR-OUTPUT.
133. Should SETDIFFERENCE be renamed to be SET-DIFFERENCE?
Yes.
134. Should PUTHASH take arguments in the order key, hash-table,
value?
This is no longer relevant; see issue 10.
135. Is it all right to make UNION and INTERSECTION take only two
arguments, in order to accept the :TEST keyword?
Yes.
136. Consider changing BUTTAIL back to LDIFF.
Yes.
137. Is the definition of CHARACTER acceptable?
Yes.
138. Should GCD and LCM take any number of arguments, or exactly
two?
Leave them alone, taking any number.
139. Should there be a DO-PROPERTIES to complement MAP-PROPERTIES?
Flush them both.
140. Should REMOB get a better name, say UNINTERN?
Yes.
141. Should there be a DEFPR to replace DEFPROP, or should this
just be flushed?
Flush DEFPROP.
142. Should RANDOM take a RANDOM-STATE as an optional argument,
rather than looking at a special variable?
Yes; the optional argument defaults to the special
variable now defined.
143. Add a SUSPEND function? What are its defined properties?
No.
144. Make the character-bag in STRING-TRIM optional, defaulting to
the space character (alternatively, all whitespace
characters).
No; it would be too confusing, and it's not hard to
specify the bag explicitly. The character-bag may be
any sequence containing characters.
145. Should REMAINDER be renamed REM?
No; too much chance of confusion with REMOVE or
REMPROP.
146. Should something be done about the fact that BYTE specifiers
use a start-count (actually, a count-start) convention, while
the rest of the language uses a start-end convention?
This is a duplicate of issue 2.
147. Syntax for non-decimal floating-point numbers?
No.
148. Shall PRIN1 be required or encouraged to print radix
specifiers in lower case (e.g., #O instead of #O) for
readability?
Yes, required.
149. Rename GET-PNAME to SYMBOL-PRINT-NAME.
Yes. Moreover, create a series of five parallel
names:
symbol-pname
symbol-package
symbol-plist
symbol-function
symbol-value
150. Disposition of BOOLE: should it be as in MACLISP? Should it
remain two-argument? Should it have the hairy EAK
definition?
As far as COMMON LISP is concerned, it takes two
(that is, three) arguments.
This is the last of the issues on the original agenda. The
following additional items were brought up at the meeting.
151. Shall FIRST and its friends be provided?
The following shall be added to COMMON LISP: FIRST,
SECOND, THIRD, FOURTH, FIFTH, SIXTH, SEVENTH, EIGHTH,
NINTH, TENTH, and REST, all operating on lists only.
152. Should 1E3 be considered to be floating-point syntax?
MACLISP says no, Lisp Machine LISP and INTERLISP say yes.
Yes.
153. Should TRACE be a special form or a function?
A function, taking a function spec and keyword
arguments. A proposal will be forthcoming.
154. A proposal for CHECK-ARG-TYPE will be made.
155. Should there be a predicate KEYWORDP?
Yes.
156. There will be a proposal for lambda macros and compiler-only
macros (optimizers).
157. Should there be a TREE-EQUAL predicate that takes a :TEST
keyword for use on leaves?
Yes.
158. Consider the naming conventions of T:
- XXX? instead of XXXP for predicates.
- All special variables have names beginning and ending
with ``*''.
No action.
159. Mention prominently in the section on the reader that the
characters !?[]{} are reserved for user read-macros.
160. DLW will propose an improved error-handling system.
161. Should FUNCALL* be eliminated, and APPLY generalized to be
FUNCALL*?
Yes.
-------