[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
- To: pierson@MULTIMAX.ARPA
- Subject: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Tue, 8 Dec 87 12:47 EST
- Cc: firstname.lastname@example.org, KMP@STONY-BROOK.SCRC.Symbolics.COM
- In-reply-to: <8712072337.AA01737@multimax.ARPA>
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>
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
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.
Edit history: Version 1 by Pierson 12/5/87
Issue: For Internal Discussion
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.
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.
This is a good example.
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.
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
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."
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.