[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

status: remaining ISSUES.TXT file



For the record, this is the remainder of the issues file that Scott worked on -- was it 1.5 years ago -- that I don't believe have made it into proposals yet. This is my "working copy":

This file contains a list of issues and proposals for the X3J13 cleanup
committee to consider.  It is broken into several sections, divided by a
line of ='s.

* Editorial changes: items that merely clarify what must currently be
   decyphered out of CLtL; not changes to Common Lisp but to the language
   describing it.

* Simple clarifications: items that are unclear, contradictory, or
  underspecified in CLtL.  In these cases, the proper fix seems obvious.

* Complex clarifications: these may require a bit more discussion.

* Simple changes: proposed small changes that may or may not be
  desirable.

* Complex changes: these are more complex or fundamental changes that
  will probably require extensive discussion.  Some of them require the
  development of a specific proposal.

* Proposed additions: these are additions or compatible extensions that
  may or may not be worth adding to the language.  Some of them require
  the development of specific proposals.  In general, these are less
  urgent than the clarifications and proposed changes.

* Issues to pass along to the compiler committee.

The clarifications on Steele's list of Jan, 1986, are included here
except for those that have been withdrawn or extensively modified by
later discussion.  The initial judgements about which issues are simple
and which are complex were made by Scott Fahlman, who has frequently
been wrong about such things in the past.

This file does not currently reflect proposals made after the August
1986 Lisp conference.  The formal proposals discussed just before the
Lisp conference are included here, more or less as place-holders.  I
have not yet dug through the relevant mail to find all of the options
and amendments that were proposed in the course of discussion.

The plan is to have the "cleanup" subcommittee of X3J13 turn these
issues into a series of proposals that will be sent to the Clisp mailing
list for comment, then to the full X3J13 committee, which will consider
whether to include these changes in the forthcoming Common Lisp
standard.

Editorial changes:

---------------------------------------------------------------------------
(p ???)
Modify the general rule about operating only on active elements of arrays to exclude ADJUST-ARRAY, SETF of AREF, ROW-MAJOR-AREF, and SETF of ROW-MAJOR-AREF.
---------------------------------------------------------------------------
p ???
Modify the description of APROPOS to replace the words ``available in'' to
``accessible in,'' and specify that APROPOS on a given package finds the
same symbols that DO-SYMBOLS would.
---------------------------------------------------------------------------
"Throughout: Adopt the term "special operator" for the symbol that
introduces a special form, leaving "special form" to refer to the whole
form. Note that the name SPECIAL-FORM-P is not quite accurate, since it acts on the symbols that introduce forms rather than the forms themselves."


p 274: Clarify by example that NSUBST-IF-NOT is perhaps non-intuitive:
    (let* ((item-list '(numbers (1.0 2 5/3) symbols (foo bar)))
	   (new (nsubst-if-not '3.1415 #'numberp item-list)))
      (values new item-list))
    => 3.1415
---------------------------------------------------------------------------
Page 113:
Clarify that the bindings created by FLET and LABELS have lexical scope
and indefinite extent.  The functions themselves have indefinite extent.
---------------------------------------------------------------------------
Page 426:
Make explicit that when a compiled file is loaded, symbols naming
lexical variables in the code may or may not be created.  This is left up
to the implementation.

===========================================================================
SIMPLE CLARIFICATIONS:
---------------------------------------------------------------------------
Page 379:

Specify that PEEK-CHAR operations on echo streams should not echo.  The
echo occurs when the character is actually read.  (We may have to add "on
systems which can manage this", since there may be some that cannot.)
---------------------------------------------------------------------------
Page 404:

Specify that the ~< ... ~> directives to FORMAT divide the whitespace
evenly into the gaps between the units of text.  Any remaining quanta of
whitespace are distributed into gaps from left to right, not placed
randomly.
---------------------------------------------------------------------------
Page 140:

Clarify that in an UNWIND-PROTECT, the cleanup forms are executed in the
dynamic environment of the UNWIND-PROTECT itself.
---------------------------------------------------------------------------
Page 51:

Clarify that coerce MAY NOT copy the argument if it is already of the
correct type.  (At present, the manual is inconsistent on whether a copy
is allowed.)
---------------------------------------------------------------------------
Page 426:

Clarify what the :VERBOSE and :PRINT options to LOAD do, or at least what
their intent is.

One proposal, by SEF:

1. Load with no switches should not print anything on standard-output.

2. The :verbose switch is intended to print some per-file information
and an indication when the loading is done, but not something for every
form that is loaded.

3. The :print switch is intended to cause the read/eval/print loop's
output to be printed, or if the file is compiled, something for each
form that is loaded.

4. These are only guidelines covering the intent of how these switches
are to be used.  Implementations are free to indicate this kind of
information in other ways if that makes sense in their environment.

---------------------------------------------------------------------------
Page 67:

Clarify that argument-list init-forms are NOT lexically within the block
established by the Defun of which they are a part.  (Most implementations
have done it this way.)
---------------------------------------------------------------------------
Page 422:

Clarify that WITH-OPEN-FILE returns the value(s) of the last form in the
body.
---------------------------------------------------------------------------
Page 200, 215:

Clarification: Division by 0 should be documented to be an error.  It
doesn't seem to be at present.

[For flonums, maybe allow IEEE-type infinities here.  Wait for error
proposal before discussing whether error must be signalled and how.]
---------------------------------------------------------------------------
Page 50, 307:

Clarification: It is an error to redefine an built-in type via DEFSTRUCT or
DEFTYPE.  [Coordinate with object proposal.]
---------------------------------------------------------------------------
Page 316:

Clarify that if a defstruct specifies a BOA constructor, the default
keyword-style constructor is not also defined.  (OR clarify that it is.)
---------------------------------------------------------------------------
Page 280:

Clarify that the :KEY argument to ASSOC is applied to the car of each list,
not the whole pair.
---------------------------------------------------------------------------
Page 104:

In the description of the second value of a setf method:

    A list of *value forms* (subforms of the given form) to whose values
    the temporary values are to be bound.

preface the parentheical remark with "often" or "usually".  It is not
always true, as in the following example:


    (DEFMACRO ELT-IF (SEQ PRED IND1 IND2)
	`(ELT ,SEQ (IF ,PRED ,IND1 ,IND2)))

The setf method of (ELT2 S P A B) is defined to be the same as that of
(ELT S (IF P A B)).  There is no way to express the setf method of this
form in terms of the values of subforms of (ELT2 S P A B), since A and
B are not always evaluated.  In the implementations I have checked, the
setf method of (ELT2 S P A B) has value forms S and (IF P A B).

The current statement is also harmful if read as a prescription for
DEFINE-SETF-METHOD, since it is then impossible to define SETF methods
for forms that do not always evaluate all of their arguments.
---------------------------------------------------------------------------
Page 130:

Specify that constant forms such as strings may appear at top-level in a
tagbody, but that only symbols and integers are considered to be tags.
It is an error to use anything else as the destination tag for a GO.

Specify that it is an error for the same (EQL) tag to appear more than
once in the body of a TAGBODY.  (However, a TAGBODY may have the same
tag as another TAGBODY in which it nests, in which case the tag in the
outer TAGBODY is shadowed, as already specified.)

===========================================================================
COMPLEX CLARIFICATIONS:
---------------------------------------------------------------------------
Page ???:

It is not specified what happens when the same (EQL) variable appears more
than once in a lambda-list or binding form (LET, LET*, etc.).  This was
discussed at some length in June/July 1986.  Possible options:

1. It is an error.
2. Latest (rightmost) binding governs in all forms.
3. It is an error in parallel-binding forms and lambdas, but rightmost
   governs in serial-binding forms such as LET*.

[Related issue: special dispensation to allow multiple uses of ignored
variables?  Bring back IGNORE as a universally-ignored variable?]
---------------------------------------------------------------------------
Page 68:

(merge with LISP-SYMBOL-REDEFINITION)
Clarify that using DEFCONSTANT to redefine any constant described in the
Common Lisp specification is an error.

Clarify that if the user defines a constant, compiles code that refers
to that constant, and then redefines the constant, then behavior of the
compiled code may be unpredictable.  It is an error to execute such
code.

Clarify that it is not an error to issue a second DEFCONSTANT command
for an existing constant iff the new value is EQL to the old one.
[Needed for reloading compiled code files.]
---------------------------------------------------------------------------
Page 413, 424:

The semantics of TRUENAME and PROBE-FILE on open streams
needs to be clarified.  The requirement that PROBE-FILE never return
NIL on an open file is clearly broken.  Spice Lisp currently
implements TRUENAME and PROBE-FILE in the same way, except that
TRUENAME errors instead of returning NIL.  Someone (Moon, I believe)
suggested that (PROBE-FILE <stream>) was the same as 
(PROBE-FILE (PATHNAME <stream>)), but that (TRUENAME <stream>) was
somehow different.  There also needs to be some discussion of the
meaning of operations on closed streams.  The manual never says which
operations may be done on closed streams, let alone what the
operations do.
---------------------------------------------------------------------------
Page ???:

Define carefully which returned values may be shared structure.  These
must not be destructively modified (or should be copied if you want to
be safe).  Symbol name-strings, rest-arg lists...
---------------------------------------------------------------------------
Page 93:

Clarify that MACROLET shadows any setf function for the associated macro:
  (DEFUN LOSER (X)
    (CAR X)
  (DEFUN SET-LOSER (X Y)
    (SETF (CAR X) Y))
  (DEFSETF LOSER SET-LOSER)
  (DEFUN LOSSAGE (X Y)
    (MACROLET ((LOSER (X)
	         `(SYMBOL-VALUE ,X)))
      (SETF (LOSER X) Y)))
LOSSAGE calls SET, not SET-LOSER.
---------------------------------------------------------------------------
Page 113:

Clarify that FLET shadows DEFMACRO. 
---------------------------------------------------------------------------
Page 321:

Modify EVAL to have an optional environment argument.
[I think this is unwise. -- SEF]
---------------------------------------------------------------------------
Page 440:

Specify explicitly that one may trace macros as well as functions.
[Is this feasible in all implementations? CF CLOS trace proposal]
---------------------------------------------------------------------------
Page 80:

Clarify what EQUAL and EQUALP do on structures.  Proposal: If the
structures are of the same type, both EQUAL and EQUALP do component-wise
comparison.
---------------------------------------------------------------------------
Page 112:

Clarify Compiler-Let or flush it.  [SEF: Flush it.]
---------------------------------------------------------------------------
Page 389:

Need a portable way to print a #\SPACE as " ".  (FORMAT NIL "~C"
#\Space) may or may not do this.  Same with PRINC.  For Standard
characters, it is safe to be more specific about how things are printed.
---------------------------------------------------------------------------
Page 160:

Either specify that IGNOREd arguments do not generate a warning if you
use them after all, or add a new declaration IGNORABLE.

[Stupid issue, discussed to death earlier.]
---------------------------------------------------------------------------
Page 295:

Proposed clarifications regarding fill pointers:
  If no fill pointer is specified to Make-Array, the implementaiton is
    not required to supply a fill-pointer, but may do so.
  If a destructive sequence function such as DELETE is passed an array
    with a fill pointer, it may change the active size of the array by
    manipulating the fill pointer; it is not required that the underlying
    array's ARRAY-DIMENSION be altered.
  If ADJUST-ARRAY is called on a vector with a fill pointer, but is not
    given a :FILL-POINTER argument, the fill-pointer is retained and is
    reset to the new length of the vector.
---------------------------------------------------------------------------
Page 249 and elsewhere:

What is the effect of giving circular lists to MAP, MAPCAR, SOME,
EVERY, etc.?  Specify that it is an error, or require it to work?

[ There's a real split on this issue.  To some people, circular lists
are a clever hack and this obviously should work.  To others, they are
an evil that should not be encouraged.  SEF and GLS have argued in favor
of treating this as an error. ]
---------------------------------------------------------------------------
Page 307:

Does COPY-FOO (where foo is a structure) work on subtypes that include
FOO?  Does COPY-PERSON work on ASTRONAUT?

[Subsumed by object proposal?  Gregor suggests: COPY-xxx as defined by a
defstruct returns a structure of that defstruct's type.  COPY returns a
structure of the same type as its argument.]
---------------------------------------------------------------------------
Page 152:

Clarify (figure out) how MACROLET and *MACROEXPAND-HOOK* interact.
---------------------------------------------------------------------------
Page 447:

Clarify by example what sort of thing goes into
LISP-IMPLEMENTATION-TYPE, etc.
---------------------------------------------------------------------------
Page ???:

Clarify the ways in which an implementation may extend pure Common Lisp:
Extra keywords to specified functions?  To all functions?  Extra return
values?  Functions working on otherwise illegal types?  Require a compiler
mode that catches non-Common stuff?  Should we document certain specific
functions (e.g. COMPILE) as allowing implementation-specific keyword
extensions. (cf IF-BODY discussion)
---------------------------------------------------------------------------
Chapter 23:

Pathnames and the file system interface require much clarification and
probably some changes.  A comprehensive proposal is needed here.
The Symbolics solution might work for us.  If we can't fix this up, we
should consider dumping the whole thing and going with something very
simple and minimal, such as a raw string in system-specific format to
designate a file.
---------------------------------------------------------------------------
Page 145:

Specify that the &REST or &BODY argument to a macro may be the very list
 from the macro call, and not a copy, and therefore the user should not
perform destructive operations on it.
---------------------------------------------------------------------------
Page 60:

Decide whether an &rest arg is required to be a freshly-consed list or
whether it may be part of a pre-existing list passed in by APPLY.
---------------------------------------------------------------------------
Page 162:

Decide what the behavior of (THE (VALUES ...) form) should be.  Does it
specify exactly how many values should be returned, or a lower limit, or
what?

One proposal: in (THE (VALUES ...) form), the form may return more
values, but not fewer, than the number of types specified in the (VALUES
...) form, and any extra values are of unrestricted type.
Also specify that (THE type form) where type is not (VALUES ...) is
equivalent to (THE (VALUES type) form).

[Discussed June/July 1986.]

===========================================================================
SIMPLE CHANGES:
---------------------------------------------------------------------------
Page 239:

Change CHAR-EQUAL, CHAR-NOT-EQUAL, CHAR-LESSP, CHAR-GREATERP,
CHAR-NOT-LESSP, and CHAR-NOT-GREATERP to consider two characters to be
different if their bits attributes are different.

[May be subsumed under a wholesale redesign of character objects,
eliminating the BIT and FONT attributes. Character committee??]
---------------------------------------------------------------------------
Page 202:

Define (LCM) to return 1 (the manual is incorrect in claiming that the
result should be infinity).
---------------------------------------------------------------------------
Page 377:

Extend READ-DELIMITED-LIST by adding one more optional argument,
dot-permitted-p, defaulting to nil, that if true allows the delimited list
to contain dot notation, and if false forbids dot notation.
---------------------------------------------------------------------------
Page 323:

Eliminate the ENV argument to APPLYHOOK, which is useless.
---------------------------------------------------------------------------
Page 418:

Flush :DIRECTION :PROBE as an allowable argument to OPEN.
---------------------------------------------------------------------------
Page 171 ff:

All functions that take a package as an argument, except those
named PACKAGE-xxx, will also take a string or symbol and do an implicit
find-package.  This gives users maximum flexibility and minimum confusion.
---------------------------------------------------------------------------
Page 316:

BOA constructors take keywords, with the obvious semantics.
---------------------------------------------------------------------------
Page 251:

(reduce #'+ list-of-objects :KEY #'object-quantity) would apply the
function OBJECT-QUANTITY to each element of the list-of-objects before
reducing it with +.
---------------------------------------------------------------------------
Page 327:

Functions that require a string, pathname, stream, or symbol
should not accept a symbol.  NIL is confusing, and some implementations
use symbols for certain streams.  [Proposal by Moon]
---------------------------------------------------------------------------
Page 305:

Require that structures (created without the :TYPE specifier) are
disjoint from the other built-in types such as vector?  They already
must be distinguishable from plain old vectors.
---------------------------------------------------------------------------
Page ???:

Forbid implementations to produce unsolicited output to
*standard-ouput*.  Output to *error-ouput* is always OK.
---------------------------------------------------------------------------
Page 444:

In the description of Decoded Time format, the Time-zone component is
required to be an integer which is the number of hours west of GMT.
(The latest term is Coordinated Universal Time, or UTC, by the way).
Since time zones are not always an integral number of hours west of GMT,
this should be changed to either (a) a non-complex, non-negative number
which is the number of hours west of GMT, or (b) an integer which is the
number of {minutes, seconds} west of GMT.

===========================================================================
COMPLEX CHANGES:
---------------------------------------------------------------------------
Page 210:

Change the branch cuts of the ATAN function to follow W. Kahan's
recommendations.  (Paul Penfield intends to recommend the same change to
the APL community.)  

[Steele should produce a specific proposal without forwarding pointers.]
---------------------------------------------------------------------------
Page 181:

There must be a package with only the official Common Lisp symbols,
either named LISP or COMMON-LISP.  Work out where
implementation-specific extensions go.  Several proposals exist.
---------------------------------------------------------------------------
Page 80:

EQUAL should descend into arrays, if they are the same type and
dimensionality, comparing leaves by EQL.

[SEF: I was partly to blame for the decision not to do this.  I now
believe that we blew it here, and should consider un-blowing it.  The
change will break some code, but the community might accept it anyway.]
---------------------------------------------------------------------------
Page 26, 42:

Alter the LIST type-specifier to distinguish proper lists from others and
to specify the element-type of the list.
---------------------------------------------------------------------------
Page 93:

Flush MACROLET, thereby doing away with environment arguments and related
confusion.

[This has been proposed N times and rejected each time on the grounds that
MACROLET is not *totally* useless, but I still think that this is the right
thing to do. -- SEF]
---------------------------------------------------------------------------
Page 154:

Eliminate the provision that a macro at the start of a body may expand
into a declaration.

[KMP, who was one of the more vocal proponents of this feature, has
now suggested that we consider flushing it.  It requires some confusing
environment hackery to do this right.]
---------------------------------------------------------------------------
Page 322:

Flush *applyhook* and *evalhook* and related hackery.  Does anyone use
this (correctly) for anything other than implementing steppers?  If not,
it may be preferable to forget about portable stepper hooks and make
stepping an implementaiton-dependent facility like DEBUG.  These hooks
cause an awful lot of confusion and anxiety for users and implementors.
---------------------------------------------------------------------------
Page 153:

Proposed alterations to SPECIAL declaration and possible addition of
UNSPECIAL (see Common Lisp mail around July 1986 including proposal by
Pavel).  One or more coherent proposals have to be constructed for
consideration.
---------------------------------------------------------------------------
Page 58:

Turn the warning that standard macros should not expand into
non-standard special forms into a requirement.  Makes life easier for
code-walkers.

[Can all implemenations live with this?]
---------------------------------------------------------------------------
Page ???:

Three related, controversial proposals on case-sensitivity for symbols. 

1)  Add a switch that would tell read and friends to suppress case
conversion, along with a note indicating that portable code assumes this
switch to be OFF.  

[SEF: This is the proposal dear to the unix people.  I still think that
it is asking for trouble to put this in.  Some code will assume this
switch despite the warning, some won't, and the two kinds of code will
not mix.]

2) Alternatively, think again about making the language case-preserving,
but with INTERN ignoring case completely.  This means that there is *NO*
way to create two symbols, one named "FOO" and the other named "foo",
but now that we have strings this may not be necessary.

[SEF: I now believe that this is what we should have done, but it is
probably too radical a change to consider at this point.]

3) Add a property of read tables which tell whether READ under the read table preserves case.  READ-CHAR is not affected.

[LMM: This is the way Xerox Lisp handles it, and it works very well. It puts case sensitivity where it belongs, as part of the read-table description.]
---------------------------------------------------------------------------
Page 171:

Even if we keep the status quo for symbols, we may want to reconsider
the rules on case-sensitivity for package names.  Need a specific
proposal and analysis of transition strategy.
[LMM: this is unnecessary, I think.]
---------------------------------------------------------------------------
Page 382:

How to communicate the current depth in printing when there are
user-defined print functions?  Guy said that what had in mind was that
the user would bind *print-level* according to the depth arg supplied to
the print function, but there were several problems with this.  Most of
the tasteful solutions involved adding new args to WRITE which indicated
the nature of the recursive use of the printer.  Others objected that
nobody wants to use WRITE directly, so that isn't a real fix.
---------------------------------------------------------------------------
Chapter 13:
[Not in cleanup committee....]
We need a comprehensive proposal for handling extended characters
(16-bit char-code, plus possibly other fields) and strings of extended
characters.  The Japanese are developing a Kanji standard.  Maybe we
can just adopt this; certainly we must coordinate with it.

At the same time, consider whether to retain the char-bit and char-font
fileds in present form.  Since an implementaiton may omit these fields,
this should not break truly portable code.
===========================================================================
PROPOSED ADDITIONS:
---------------------------------------------------------------------------
Page ???

Add a new function TYPE-SPECIFIER-P that is true of valid type
specifiers and false of all other Lisp objects.  Note that the use of
DEFSTRUCT and DEFTYPE can change the behavior of TYPE-SPECIFIER-P over
time. (Discussed by not good results).
---------------------------------------------------------------------------
Page 226:

Add SIGNED-LDB.  Like LDB but sign-extends the extracted byte.
---------------------------------------------------------------------------
Page 283:

Add functions HASH-TABLE-REHASH-SIZE, HASH-TABLE-REHASH-THRESHOLD,
HASH-TABLE-SIZE, and HASH-TABLE-TEST each take a hash table and return
the appropriate current information.

[ Which, if any, are SETF-able?  What does hash-table-test return, the
function object for the test function? ]
---------------------------------------------------------------------------
Page 439:

Add COMPILEDP.  This takes a function and returns non-NIL if it is a
compiled function, and NIL if it is not.  If the function is a symbol
whose compiled-function definition was installed by the COMPILE
function, then the non-NIL value returned is the interpreted definition
that was compiled.
---------------------------------------------------------------------------
Page 439: 

Add UNCOMPILE.  This takes a symbol and restores the previous
interpreted definition of that symbol if that symbol previously had an
interpreted definition and was then given to COMPILE; otherwise no
action is taken.
---------------------------------------------------------------------------
Page 447:

Add USER-NAME.  This returns a string identifying the user of the Common
Lisp system, or NIL if that cannot be determined.
---------------------------------------------------------------------------
Page 327:

Add *DISCARD-OUTPUT-STREAM* (alias, the bit bucket).
[Make this a constant so that it can be optimized?  You should never want
to rebind this to another value.]
---------------------------------------------------------------------------
Page 117:

Add (CASE-WITH-TEST test item ...clauses...).
---------------------------------------------------------------------------
Page 51:

Extension: Let COERCE coerce symbols to strings.  NIL is treated as the
empty sequence, not a symbol.  Also let COERCE turn string-chars into
strings of length 1.
---------------------------------------------------------------------------
Page ???:

Add TRUE and FALSE, functions that take any number of args, ignore them,
and return T and NIL respectively.
Someplace:
---------------------------------------------------------------------------
Page 95, 267:

Add SETF of NTHCDR.
---------------------------------------------------------------------------
Page 158:

Add a TYPE-RESTRICT declaration.  (TYPE-RESTRICT type1 type2), where
type2 is a subtype of type1, says that within the scope of the
declaration if the compiler can prove a value is of type1, it is
allowed to assume that it is of type2.  This gets rid of a lot of
multiple-THE forms when you want maximally tense code.
---------------------------------------------------------------------------
Page 73:

Fill out the set of mumble-P type predicates.  Currently we have some
and not others.
---------------------------------------------------------------------------
Page ???:

We need a set of "undoing" functions, so that interactive errors and
failed experiments can be recovered from without starting over.
See comprehensive proposal by Eric Benson.

[SEF: A generic "undo" facility, like SETF, has been opposed on various
occasions, but is a bad idea because users will expect too much of it,
and complain when it doesn't undo everything.]
[cf DEFINITION-FUNCTIONS, in prep]
---------------------------------------------------------------------------
Page 336:

Add (syntax-type <character>), which returns one of the following:
:illegal, :whitespace, :constituent, :single-escape, :multiple-escape,
:terminating-macro, :non-terminating-macro.

[Make this setf-able?  If so, what do we do about macro characters that
have no definitions?]
---------------------------------------------------------------------------
Page 283:

Add EQUALP hash-tables?  Case-insensitive hash-tables for strings?  Let
the user provide his own test (with associated hashing function)?  [Need
a coherent proposal.]
---------------------------------------------------------------------------
Page ???:

Have a function COPY that can copy any single object.  For a CONS cell
it would copy just that CONS.  Whether (EQ X (COPY X)) for X a character
or number is implementation-dependent.

[Proposal in archives by Morrison, needs some tuning.]
---------------------------------------------------------------------------
Page 171:

We need a way to say "use all the symbols from package FOO except for X,
Y, ..."  Shadowing is no good, since you might want to inherit X from
somewhere else.  Also, do we want a make-package that says ALL symbols
get exported?
---------------------------------------------------------------------------
Page ???:

Fahlman's proposal for &more arguments, similar to &rest but leaves the
arguments on the stack LEXPR-style.  Removes one of the worst inherent
efficiency problems in Common Lisp.
---------------------------------------------------------------------------
Page 438:

Review and develop a general philosophy on the handling of semi-standard
system interface functions such as GC, BYE, ED, SAVE-SYSTEM, etc.  Then
see what we want to add (or remove).
---------------------------------------------------------------------------
Page ???:

Consider FUNCTION-PARAMETERS and related proposals that were discussed
extensively in June/July 1986.
---------------------------------------------------------------------------
Page ???:

Consider PARSE-BODY and extended syntax for &BODY, as discussed in
June/July 1986.

[Note, if we flush MACROLET or eliminate macro-expansion into
declarations, this extension becomes less critical, though it may still
be useful.]
---------------------------------------------------------------------------
Page 154:

Permit declarations before the body of a LABELS, FLET, or MACROLET.

===========================================================================
For the compiler committee:
---------------------------------------------------------------------------
A lot of compiler/eval-when issues need to be settled.  Among the
issues: Define clearly how REQUIRE interacts with the compiler.  Are
DEFSETF-generated available in the compiler environment by default?
---------------------------------------------------------------------------
Package interactions with COMPILE and LOAD need to be worked out better.
Restrict IN-PACKAGE, IMPORT, and firends to the start of files only?
Add a new declarative form to handle this?  Some favor legitimzing -*-
forms, but this is unacceptable to many.
---------------------------------------------------------------------------
Related issue: Add INCLUDE, or some other way to stuff multiple source
files into one binary?  (Package hackery makes this complicated.)
---------------------------------------------------------------------------
Related issue: There should be some discussion of the semantics of
compilation on literal constants (things appearing in quoted structure
in code).  To what degree is sharing and non-sharing preserved?  Many
implementations both introduce and remove sharing.  Probably most don't
dump circular structures.
---------------------------------------------------------------------------
What things can a compiler optimize by inline expansion, tail-recursion
elimination, etc.?  What things must be handled correctly if the user
redefines a built-in function (or specializes it using the object
facility)?

Proto-proposal: All built-in functions may be optimized inline
(and therefore do not respond to later modifcation) unless this is
inhibited with a NOTINLINE declaration.  Maybe create a list of
functions such as PRINT that are not open-coded by default.  Also,
within a DEFUN, a recursive call to the function being defined may be
optimizied into a jump, unless this is inhibited by NOTINLINE.  (Maybe
think up a better term than NOTINLINE.)
---------------------------------------------------------------------------


NEW:

Declare *print-circle* means to print out shared structure too. Alternative: add another variable *print-shared*. Alternative: add another value to *print-circle* (nil :none   t :unspecified :circular :shared).