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

list of proposed changes to Common Lisp



    (*) 107 Clarify that GET-SETF-METHOD and GET-SETF-METHOD-MULTIPLE-VALUE do
    not perform macro-expansion on the given form, and that in most contexts
    the usage should be (GET-SETF-METHOD (MACROEXPAND form env)).  Indeed,
    the simplified example version of SETF given on page 108 should be
    changed to:
    (DEFMACRO SETF (REFERENCE VALUE &ENVIRONMENT ENV)
      (MULTIPLE-VALUE-BIND (...)
	  (GET-SETF-METHOD (MACROEXPAND REFERENCE ENV))
	...))
    [Alternatively, we could specify that GET-SETF-METHOD should take an
    environment as an additional, optional argument, but that would be a
    change to the language rather than simply a clarification.]

This won't work, as it prohibits defining setf methods for macros.
GET-SETF-METHOD needs the environment so that it can expand macros one
level at a time, checking if the result has a setf method.  I also
suggest that the environment argument not be optional, as any user
code which doesn't supply it is surely broken.

    268 Have a function COPY that can copy any single object.  For a
    structure, it would use the user-specified copy function, if any.  For a
    CONS cell it would copy just that CONS.  Whether (EQ X (COPY X)) for X a
    character or number is implementation-dependent.
What does this function do in the presence of displaced and adjustable
arrays?  Are these attributes preserved, or is the result just
structurally identical?  How about a COPY-ALL function which descends
into structure until it finds something not needing to be copied?

    I have some of my own unclarities and clarifications:

If we're allowed to clarify things by adding new functions, then I
propose my own: a structural equality predicate.  It descends into
arrays and structures, but compares leaves with EQL.  This is what
EQUAL should have been, but couldn't for hysterical reasons.
("Descending into arrays is too inefficient.", to which I reply "Not
if you want to compare arrays.")  As far as equality predicates go,
arrays are still second-class citizens of the language.

312 It should be explicitly noted somewhere that defstruct copiers
work on structures which are a subtype by inclusion, e.g. COPY-PERSON
works on an astronaut.  This is a natural consequence of the subtype
semantics of inclusion, but isn't necessarily obvious to pea-brained
implementors.

416 I think that the DEFAULTS argument to MAKE-PATHNAME should be
allowed to be an arbitrary thing, rather than being constrained to
being a pathname.  All other pathname args can be any thing accepted
by PATHNAME.

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.

410 There should be some clarification of what can be expected from
implementations where some of the pathname components are meaningless,
i.e. host and version.  Must these fields actually exist in the
pathname object?  What must the operations do with these fields?

419 Are implementations really required to support all those element
types?  (signed-byte 1234567)?  I guess arbitrary restrictions would
be allowed by the implementation note on 421, but it doesn't really
apply here.  It is possible in any filesystem to implement I/O of all
these things.  The question is whether it's worth the effort.

419 I believe that everyone agreed that :DIRECTION :PROBE was silly
and should be flushed.

438 There should be some discussion of the semantics of compilation on
literal constants (things appearing in quoted structure in code).
 1] What types of objects may be constants?  Surely not any, as some
    implementations find it impossible to dump things such as compiled
    function objects.
 2] To what degree is sharing and non-sharing preserved?  Many
    implementations both introduce and remove sharing.  Probably most
    don't dump circular structures.
 3] How does symbol dumping and loading work?

Since the reference model for compilation is that "it may run faster",
it seems that ideally the semantics of loading a compiled file should
be indentical to those of loading the source.  This goal is
unrealistic, since the reading of the source by the compiler loses
information.  A better model is that compilation and loading should be
similar to printing and reading again.  This is probably excessively
restrictive, but may also be too liberal in that it suggests that
circular structures can be dumped.

  Rob