GNU bug report logs - #20056
25.0.50; Remove non Common Lisp stuff from cl*.el libraries

Previous Next

Full log

Message #32 received at 20056 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Daniel Colascione <dancol <at> dancol.org>, 20056 <at> debbugs.gnu.org
Subject: RE: bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el
 libraries
Date: Sun, 8 Mar 2015 14:31:08 -0700 (PDT)

> > It is perfectly fine to extend or redesign Emacs Lisp any way we
> > like.  And we can take whatever we want from Common Lisp and do
> > whatever we want with it.  We need not try to emulate any given
> > Common-Lisp function or macro.  But the things we put in the
> > Common-Lisp emulation package should be emulations of Common Lisp
> > things, IMO - things designed by the Common-Lisp designers for
> > Common Lisp.
> >
> > It is not appropriate to add non Common-Lisp things to our
> > emulation of Common Lisp.  That's all.
> 
> I think cl-lib has long ago stopped being an emulation of common lisp.

What makes you think so?

Even if that were true, it's not a reason not to clean it up now.

And if it is not to be cleaned up, what criteria (3rd time asking)
do you apply to decide what goes into it and what does not?

> Now, it's a CL-*inspired* utility library. 

What does that even mean?  Inspired how?  What criteria define
what is or is not a "CL-*inspired* utility"?

If ever there was a huge language that touches nearly everything
and nearly every software engineering construct/approach, it's
Common Lisp.  What is not a "CL-*inspired* utility"?

> I doubt that there's a risk of real harmful confusion between
> this library and actual Common Lisp.

Google for `letf' and you will find that just such confusion
has occurred.

And there is no reason for it.  That's the point - it doesn't
have to be this way.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.