MEMBER, MEMBERP

[Kent M. Pitman <KMP @ MIT-MC>]

When this subject came up the last time, it was argued by several people that
most usages of MEMBER were due to people using numbers in lists, since numbers
aren't guaranteed EQ. It was argued that most people were using MEMBER where
they really didn't need all its power. I was mildly against this move when it
originally came up, but in checking back over pieces of code I've written, 
there are very few places where it would matter and I'm inclined to buy the
argument that those few places should be changed in the mechanical way 
suggested in order to clean up the language.

I think the right approach to any compatibility packages might be to make
a MACLISP: package which people could build inferiors to if they didn't like
LISP:. It could shadow things like MEMBER, etc. and define them with the old
semantics.

I can't believe this problem is the only one of its kind in Common Lisp. There
are other incompatible changes. Code will have to be looked over before it can
be said to be running correctly anyway. At this point, I see the goal of 
compatibility to mean not that code would run directly but more that code 
could be mechanically translated (rather than requiring major re-thinking)
in order to run. The implementors need to decide if this is in fact what they
intend. If the claim that CL really needs to run code compatibly with
existing dialects is true, there are a pile more changes we'd better start
making right now. If, instead, the claim is that the language will successfully
support a compatibility mode (eg, a MACLISP: package to build systems under,
or a MACLISP => COMMON-LISP translator), then I think the change to MEMBER is
certainly among the least dangerous of the changes being made and I think it's
a very poor precedent to set.

Common Lisp is, and always has been, dangerously on the brink of being too
wishy-washy to be a good language in and of itself. It has had to yield to the
needs of so many design constraints from so many applications that it's been
difficult to pull together. My feeling is that its overall effect will probably
be positive because it did actually rise above quibbles with absolute 
compatibility and try to present itself as less of a hodge-podge than most of
the languages it seeks to make compatible. Regularization of naming and
semantics of operators where it has happened, even where the possibility
exists of introducing an incompatibility with some dialect, is perhaps the
most important contribution of the language.

I think we should just stand with the spec we've got, provide users with as
much data we can about mechanical rewrites they'll need to do -- perhaps even
programs to help with the rewrites -- and go with that.