[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

My poll of Lisp users

I have forwarded Fahlman's message to all the Lispm users
and told them that I will let the MIT system users decide what
I should do with MEMBER.

Meanwhile, here are the answers I got.

Subject: Function MEMBER to be changed?

I agree with you that member shouldn't be changed.


Surely Common Lisp conversion will entail many other changes in code.
Why is this particular change important?


I would prefer to see MEMBER use EQUAL for comparison, as now, because
I often use MEMBER on lists of lists.


I agree with you.

From: Randy Davis <DAVIS@MIT-OZ>

let's hear it for upward compatibility; yes leave the names unchanged.

From: Christopher C. Stacy <CSTACY @ MIT-MC>

Since so many other things are going to break, I dont understand
why MEMBER is such a big deal.

From: Kent M. Pitman <KMP @ MIT-MC>

I vote yes for the change, as you probably already saw in my mail to 
Common Lisp. I was originally somewhat worried about this change, but
having looked over my code, I find it actually breaks little or nothing.
I suspect other people responding might not realize how little effect
this will actually have.

I have for a long time discouraged people from using MEMBER, which is
the nicer name, when MEMQ would be more efficient. I think the name
change will be beneficial to code appearance because the new definition
of MEMBER is nearly always the appropriate one.

When the final Common Lisp document becomes available, I may try to write
some helpful facilities for translating existing code to Common Lisp,
probably in Teco. This is definitely one of those changes that could be made
relatively easily by such a program.

From: Jeffrey P. Golden <JPG @ MIT-MC>

If you are recording votes on the MEMBER etc. CL issue, I strongly 
agree with your position on this.  Not having been aware of the prior 
discussion amongst CLers on this, when GJC mentioned to me on 6/14 
what they were planning to do to MEMBER etc. I immediately responded:
'Horrors, why didn't they just call their version MEMBERP?' (Not exactly 
in those words.)

From: Bruce R. Donald <BRD@MIT-OZ>

I use member a lot to check for "Yes" (and other strings) in a list of
menu choices. Also, (MEMBER VERTEX BOUNDARY) where BOUNDARY is a list
of vertices and VERTEX is a DEFSTRUCT of :type list would not work
with the common lisp MEMBER, no?

From: dove at mit-dspg

My personal code does not to my knowledge use member either for
lists as members or strings.  Thus, the update problem should
not affect me.  Besides, I have gotten somewhat used to changing
things to remain compatible.

To:   dove@mit-dspg

I use MEMBER and ASSOC in cases where I really mean
EQUAL, and MEMQ and ASSQ when I really want EQ.  Changing
MEMQ and ASSQ to use EQL seems reasonable, but such a change
to MEMBER and ASSOC clearly do not.

From: dove at mit-dspg

Given that member is often used on the lispm to check for strings in
things like menus, it seems that equal would be preferable.  The
crux of the issue seems to be the simplification of that code (and the
ability to leave old code unmodified) versus speed.

From: Dick@MIT-MC

I agree that there is no reason to incompatibly change the meaning of
any function unless absolutely necessary.  It sure doesn't seem
necesarry here.