more comments

["BIZET::VANROGGEN" <vanroggen%bizet.decnet@hudson.dec.com>]

1   UNDO is too vague.
    I suggest something like either
    (UNPROCLAIM '(CONSTANT FOO)) or (PROCLAIM '(NOTCONSTANT FOO))
    Same for SPECIAL. We'll need a PROCLAIM CONSTANT too.
    But wait--what will it mean to make incompatible proclamations?
    As is said in [clarification 56,58], redefining a constant is
    an error. Then surely making a constant a variable ought to be
    at least as dangerous.
    This problem is more general than just wanting to be able to "undo"
    a definition--we need to decide how to change definitions. For
    example, if one first (PROCLAIM '(FTYPE (FUNCTION STRING INTEGER) FOO))
    and then (DEFUN FOO (S I) (DECLARE (TYPE SEQUENCE S) (TYPE FIXNUM I))
    ...), is the DECLARE in error or does it supersede the proclamation,
    or does it just shadow the proclamation for the body of the function?
    What if later (DEFUN FOO (A B C) (DECLARE (FLOAT A B C)) ...)?
    Or if there's a PROCLAIM to that effect?
    I hope we can define some reasonable behavior, but I think there will
    always be some conflict between "static" proclamations and the "dynamic"
    redefinitions done during program development until some notion of
    "state" is introduced.
    Also, should DEFVAR update the documentation string even when
    the variable already had a value and thus didn't get reset?

47  The problem with the idiosyncratic use of &REST in a function type
    specifier is that we really need a more general list-type description
    without resorting to arbitrary predicates. Although &REST (INTEGER 0)
    is a cute idea, I'm mildly opposed.

60  Yes, "an error" to have two parameters be the same symbol. I assume
    "same (EQL) name" isn't really meant here, since the following should
    be OK: (DEFUN FOO (PACK1:X PACK2:X) ...)

82  XOR seems to be stretching the analogy between control constructs and
    logical operations a bit. BTW, there ought to be a mention of EVERY and
    SOME in the descriptions of AND and OR if one wants to apply their
    functionalities.

107,144 Would life, the language, and everything be simpler if MACROLET
    didn't exist?

145 I'd prefer (BODY &OPTIONAL DOCP ENV) for PARSE-BODY where DOCP
    defaults to NIL.

145 Is it OK to destroy the non-top-level list provided by &REST? Should
    this be different for macros than for functions?

158 No, this should be an error only if the types conflict.

161 Should be OK if there are fewer returned values if they still match
    the type specified. (I.e., if NIL is TYPEP the given type).

249 Hmmm. For now we can state that circular lists are "an error", just
    so the language can be more precisely defined.

307 Also watch out for a slot named "P".

321 EVAL doesn't need an environment arg--what's wrong with the existing
    EVALHOOK function?

439 I didn't mean that COMPILE had to save the interpreted definition for
    COMPILEDP to potentially return. Rather, +if+ COMPILE had saved it,
    COMPILEDP would return it and UNCOMPILE would restore it. Also, COMPILEDP
    is supposed to work on names and can be true for macros (and special
    forms, though that's not relevant), which distinguishes it from
    COMPILED-FUNCTION-P. COMPILEDP should be false for a closure over a
    compiled function, but COMPILED-FUNCTION-P should be true.

			---Walter
------