Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

I mostly support the contained proposal, but have a number of specific comments...

    Date: Mon, 07 Dec 87 18:37:19 EST
    From: Dan L. Pierson <pierson@multimax.ARPA>

    Issue:         REDUCE-ARGUMENT-EXTRACTION
    References:    REDUCE (pp. 251-252), :KEY arguments (p. 246), 
		   the astronaut structure (pp. 312-313),
		   see also REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF,
		   DELETE-IF-NOT, REMOVE-DUPLICATES, DELETE-DUPLICATES, SUBSTITUTE,
		   SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF,
		   NSUBSTITUTE-IF-NOT, FIND, FIND-IF, FIND-IF-NOT, POSITION,
		   POSITION-IF, POSITION-IF-NOT, COUNT, COUNT-IF, COUNT-IF-NOT,
		   MISMATCH, SEARCH, SORT, STABLE-SORT, MERGE (pp. 253-261), 
		   SUBST, SUBST-IF, SUBST-IF-NOT, NSUBST, NSUBST-IF, NSUBST-IF-NOT,
		   SUBLIS, NSUBLIS, MEMBER, MEMBER-IF, MEMBER-IF-NOT (pp. 273-275),
		   ADJOIN, UNION, NUNION, INTERSECTION, NINTERSECTION, 
		   SET-DIFFERENCE, NSET-DIFFERENCE, SET-EXCLUSIVE-OR, 
		   NSET-EXCLUSIVE-OR, SUBSETP (pp. 276-279),
		   ASSOC, ASSOC-IF, ASSOC-IF-NOT, RASSOC, RASSOC-IF, RASSOC-IF-NOT
		   (pp. 280-281)

I think this references list will scare people voting. I think the references is
intended to give people an idea of how sweeping the change is. If we feel strongly
that this isn't enough, we might want to have both a references and a cross-references
field. But for now I'd just leave the references as

 REDUCE (pp. 251-252), :KEY arguments (p. 246),
 the astronaut example (pp. 312-313)

and drop the rest.

    Category:      ADDITION
    Edit history:  Version 1 by Pierson 12/5/87
    Issue:         For Internal Discussion

    Problem description:

    REDUCE is the only one of the Common Lisp functions that modify or
    search lists and sequences which does not accept a :KEY argument.
    This complicates many uses of REDUCE.

    Proposal (REDUCE-ARGUMENT-EXTRACTION:KEY):

    Change the definition of REDUCE to take a :KEY keyword.

This needs to be more elaborated. You need to say what the :KEY keyword will do.
The proposal part of these write-ups is intended to stand on its own.

    Test Cases/Examples:
    ...

This is a good example.

    Rationale:

    This proposal brings REDUCE into line with the rest of the sequence
    and list modifying and searching functions at the cost of slightly
    blurring the meaning of :KEY arguments.

I would not mention the discussion of the name :KEY here at all. Leave it for
the discussion because it's confusing unless presented in full form, and it's
too much work to present here. Maybe just say:

 This proposal makes many common situations where REDUCE would be useful
 much less cumbersome.

    Current practice:

    Does anyone currently support this as an extension?
    ...

It's not worth mentioning in the proposal, but for your general information
so you don't think we didn't notice the question, Symbolics does not currently
support this.

    Aesthetics:

    Slightly damaged.  All :KEY arguments are currently defined to be used
    for predicates, this proposal will implicitly broaden :KEY to support
    general extraction for any purpose.

I might say "Slightly damaged in one way..." and then have a second paragraph
that says "Slightly improved in another way. Many common situations where
REDUCE could be used would be easier to write and easier to later read."

    Discussion:

    Several members of the committee feel that the increased functionality
    outweighs the damage to the definition of :KEY.  No one has objected
    to this change in the recent round of discussions.

There is no "definition" of :KEY. At best, it's an unwritten rule. It's arguably
just a coincidence. Anyway, the general sentiment of this paragraph is right,
but it should be worded more carefully so that it doesn't set a precedent for
"unwritten rules" having to be too strongly justified.