Re: Issue: TAILP-NIL (Version 4)

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

    Date: 2 Dec 88 09:43 PST
    From: masinter.pa@Xerox.COM

    This gives me a reason for wanting to disallow non-lists as the first
    argument to TAILP -- that it would have to use EQL to be consistent.

Having had a night to think about it, I don't think the need to
use EQL is much of an argument against.

 If the implementation does not inline TAILP, then TAILP can
 select one of two trivial loops based on its argument type.
 No significant slowdown there.

 If the implementation does inline TAILP, then it can just put
 in EQL and leave it to optimizers for variable declarations
 and/or THE to notice that things declared to be LIST (or at
 least (AND (NOT NUMBER) (NOT CHARACTER)) can be optimized).

We use effectively the same argument to justify making EQL the
proper test for MEMBER in spite of the superficial impression of
non-efficiency, so I'll be interested to hear anyone try to refute
this position.

As to the use of ENDP, I think the overriding argument has to be
that ENDP is appropriate only for list abstractions, and I absolutely
don't see this as a useful list abstraction. [Explanation below.]

As to the use of EQL, I think there is no justification for using
EQ in the language anywhere, other than providing the function itself
and providing the facility of other functions to take [#]'EQ as an
argument, and even that is fairly questionable in portable code.

The reason I don't think TAILP is an operation on lists is that all
the list abstractions go to a lot of trouble to say that cars and
cdrs can be changed willy-nilly. If you do much of anything to a list,
you have to be afraid that EQ-ness of something in the container
has been destroyed. The only thing all the list operations tend to
preserve is overall shape. Hence, it's dumb to have an operation
which claims to be about lists and yet which uses a type predicate
which is seriously inappropriate to lists. If TAILP were really
about lists, it would want to use something like EQUAL as a predicate.

I think TAILP is most useful when you've gone to some care to construct
a cdr-chain from scratch using only cons and custom maintenance 
primitives. In any case where custom primitives are involved, any
expectation that ever cdr-chain is going to be a proper list is out
the window. If you restrict TAILP to work only on proper lists, you
place an arbitrary restriction on it which makes it not useful in
a number of places where it might otherwise be useful.

I think the reason we don't have anyone arguing passionately about
what TAILP should do from experience is that it is seldom useful in
practice.

I think the reason it is seldom useful is that it is not defined on the
full set of data types that it needs to be defined on.

My now-considered position is that I am firm in the idea that the end
test should be ATOM and that the test should be EQL.