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


In going over the votes of January 1989 I have discovered the following
anomalies and propose certain amendments.  Larry, should they be written
up as formal proposals, and if so, should they take the form of separate
amendments, or should they consist of new versions of the old issues?


(1) SYMBOL-MACROLET-SEMANTICS did not address the question of how
    symbol macros interact with *MACROEXPAND-HOOK*.  I propose that
    expanding a symbol macro should result in calling the hook
    function with three arguments, just as for an ordinary macro;
    the first argument will be a special system-supplied expansion
    function, the second argument the form (a symbol, of course),
    and the third the environment.  The expansion function, when
    called on the other two arguments, will return the expansion.

(2) SYMBOL-MACROLET-SEMANTICS should perhaps also specify that
    PSETQ of a symbol-macro symbol behaves like PSETF.

(3) The LOOP Facility has an inconsistency in its examples.
    Under the description of WITH it shows the use of AND as
	(LOOP WITH binding AND WITH binding AND WITH binding  body)
    but in the discussion of destructuring an example reads
	(LOOP WITH binding AND binding AND binding body)
    The formal syntax for WITH prescribes that the word WITH should
    *not* be reiterated (but note that the specification of
    FOR/AS prescribes that FOR or AS *should* be written again--
    possibly mixing them?)
    I propose that, for consistency with FOR/AS, the formal syntax
    of WITH be changed to require the word WITH to be reiterated,
    and that the examples be changed to match.

(4) SUBTYPEP-TOO-VAGUE lists three rules:
    * Involving SATISFIES, AND, OR, NOT, MEMBER allows return of NIL NIL,
      but no other case does.
    * Error if VALUES or FUNCTION involved.
    * Must return T T if types EQUAL.
    There are cases that fall into more than one of these categories,
    and the proposal as approved did not specify a priority ordering
    among them.
    I happen to agree with the proposal of Kim Barrett to strike the
    second point, although simply striking it is not enough.  I believe
    that the first rule should take precedence over the third.
    Therefore I propose that the three points above be condensed
    simply to
    * Involving SATISFIES, AND, OR, NOT, MEMBER, VALUES. or the list form
      of FUNCTION allows return of NIL NIL; no other case may return NIL NIL.
    Note that this wording subsumes the third point: if the second value
    has to be T, then SUBTYPEP has to get it right, in which case EQUAL
    type specifiers will produce T T.

    list, but not SHORT-FLOAT or LONG-FLOAT.
    I propose to add SHORT-FLOAT, LONG-FLOAT, and RATIONAL to the list.