[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: TAILP-NIL (Version 5)
- To: Masinter.PA@Xerox.COM
- Subject: Issue: TAILP-NIL (Version 5)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Tue, 13 Dec 88 19:05 EST
- Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
- In-reply-to: <881212-151820-5387@Xerox>
Date: 12 Dec 88 15:17 PST
It was suggested more than once by more than one cleanup
committee member that we remove TAILP from the language
"since almost nobody uses it".
For the record, at least one member of the cleanup committee thinks
this sentence is
Irrelevant. Removing the operator would be gratuitous.
Inflammatory. It seems to raise the possibility of removing TAILP,
when in fact since such a move would be quickly labeled gratuitous,
only provides fodder for those who wish to muddy the water and avoid
the real issues under discussion.
Unfounded. No evidence is presented to support the claim that almost
nobody uses it. Indeed, it has been repeatedly shown that if an
operator is used at all, we have no way of evaluating what it
means for the operator to be "used a lot" (lines of code, number
of executed funcalls, dollars behind products using, ...). It happens
that this claim's probably true, but as a point of style we oughtn't
be in the habit of making anonymous, unsubstantiated claims about usage
patterns, or especially of encouraging that decisions be made based on
Shooting in the Dark. Even if an operator were not often used by some
metric(s), the suggestion that the only or best way to deal with it
is to remove it is random. There are equally good reasons to believe
that the operator would be both useful and more heavily used if its
definition were ammended to accomodate serious uses.
I, for one, have found that nearly every time I think LDIFF would
suffice, the EQL test (rather than EQUAL), and its failure to take
a test argument, has screwed me -- causing me to do what I have always
felt is needless rewrite. I have only rarely needed TAILP and I can't
remember if I ended up actually using it or not -- I'd suspect that
the constraints on it make it next to useless.
The point I want to stress is that the fact that LDIFF and TAILP have
not been what I've needed does not mean that I've not needed to find
the difference of two lists or to find if something was a subtail of
something else. The problem for me has not been that these -operations-
are useless (or nearly so) -- but rather that these -operators- are.
The cure is not necessarily to flush the operators -- it might well be
to fix them. I certainly think fixing them is the correct solution.
Only in writing this message did I become cognizant of the significance of
my problems with LDIFF and its relation to TAILP.
Btw, I just looked up LDIFF and its description suffers from a similar
non-clarity about dotted lists to that which TAILP suffers from. It
clearly admits NIL as a possible sublist, but it doesn't really treat
atoms. So, the status quo is that the relationship between LDIFF and TAILP
is not clear, the proposal TAILP-NIL:NIL would have definitely made them
incompatible, TAILP-NIL:T makes them more conceptually compatible, but
without further clarification, they will not really be compatible.
Based on this, I'm strongly tempted to suggest that we should ...
- Expand this proposal to deal with LDIFF.
- Elaborate this proposal to add a :TEST argument to both
operators. [Clearly a :TEST argument of EQUAL may be dramatically
slower, but if the alternative is to write a LOOP calling EQUAL,
the net effect is the same and the only question is how much coding
I have to do and how much the system will do for me.]
So there! That should teach you to add "harmless" little additions to the
discussion at the last minute. :-)