un-deprecating CL

un-deprecating CL

[Joe Wells]

I just saw this wonderful essay by Dave O'Toole entitled

  "(require 'cl) considered harmful" considered harmful

at this URL:

  http://dto.freeshell.org/blog/blog-2007-09-07-2323.html

I agree completely with its reasoning.

Therefore, I propose that the warnings in the manual against relying
on CL and the byte-compiler warnings when you use a CL function should
both be removed.

I hope this suggestion is helpful.

-- 
Joe

Re: un-deprecating CL

[David O'Toole]

Hello fellow Emacsians,

I would like to point out that my comments were made informally on my
blog, and that the notes at the end about "radical action" and such
are intended to be tongue-in-cheek.

I had planned to revise it further before bothering the emacs-devel
list with the issue; in particular I would have made it sound less
like a rant :-) but also would have tried to bolster my arguments a
little and see if there were other workarounds. For example, i saw the
following in the Emacs TODO file:

> ** Implement popular parts of the rest of the CL functions as compiler
>    macros in cl-macs.

and it occurred to me that I might be able to help.

My point in this is not to complain, but to see if I can help improve
things by helping other developers write their Emacs Lisp programs
more easily.  (I have found it easier to read and write my own
programs since learning the CL package, although it took a significant
investment in time to learn it.)

Joe Wells <jbw@macs.hw.ac.uk> writes:

> I just saw this wonderful essay by Dave O'Toole entitled
>
>   "(require 'cl) considered harmful" considered harmful
>
> at this URL:
>
>   http://dto.freeshell.org/blog/blog-2007-09-07-2323.html
>
> I agree completely with its reasoning.
>
> Therefore, I propose that the warnings in the manual against relying
> on CL and the byte-compiler warnings when you use a CL function should
> both be removed.
>
> I hope this suggestion is helpful.
>
> -- 
> Joe

-- 
David O'Toole 
dto@gnu.org
http://dto.freeshell.org/notebook/

Re: un-deprecating CL

[Richard Stallman]

I stand firm on that decision, and I don't have time to discuss it.

Re: un-deprecating CL

[Karl Fogel]

Joe Wells <jbw@macs.hw.ac.uk> writes:
> I just saw this wonderful essay by Dave O'Toole entitled
>
>   "(require 'cl) considered harmful" considered harmful
>
> at this URL:
>
>   http://dto.freeshell.org/blog/blog-2007-09-07-2323.html
>
> I agree completely with its reasoning.
>
> Therefore, I propose that the warnings in the manual against relying
> on CL and the byte-compiler warnings when you use a CL function should
> both be removed.

I completely agree.  The CL packaged is distributed with Emacs now.
If a programmer defines a function in a way that conflicts with CL,
the best result would be for them run into problems and have to rename
their function so as not to to conflict with CL.

Frankly, we should just have CL loaded as a default all the time :-).
But failing that, at the very least we should encourage its use, and
encourage other packages to avoid conflicting with CL's namespace.

-Karl

Re: un-deprecating CL

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Date: Fri, 14 Sep 2007 12:21:22 -0700
> Cc: emacs-devel@gnu.org
> 
> >   http://dto.freeshell.org/blog/blog-2007-09-07-2323.html
> >
> > I agree completely with its reasoning.
> >
> > Therefore, I propose that the warnings in the manual against relying
> > on CL and the byte-compiler warnings when you use a CL function should
> > both be removed.
> 
> I completely agree.  The CL packaged is distributed with Emacs now.
> If a programmer defines a function in a way that conflicts with CL,
> the best result would be for them run into problems and have to rename
> their function so as not to to conflict with CL.
> 
> Frankly, we should just have CL loaded as a default all the time :-).
> But failing that, at the very least we should encourage its use, and
> encourage other packages to avoid conflicting with CL's namespace.

For the record, I'm not as opinionated as Richard about CL, perhaps
because my Lisp background doesn't go as far back and as deep as his.
But I must say that the above blog's arguments lost me as a potential
ally right on the first sentence:

    In my opinion, the best way to program Emacs Lisp is to use the many,
    many powerful macros and functions of the CL package.

This basically says that the author is already sold on using CL as
heavily as possible, and therefore all the rest of the essay is
suspect of trying to sell the same idea to the reader.

That is not a very effective way of convincing people to assign to
views that are in controversy, IMO.

Granted, a blog isn't required to present a convincing argument.  But
if this essay does need to convince me, it will have to do a lot
better.  For example, I would like to hear about disadvantages of
using CL, not just about how wonderful it is.  IOW, a convincing
argument will present a balanced view of the issue, and try to win by
showing that the balance is in its favor.

As to the warning in the manual and the byte compiler, I hope you
realize that the name conflict is not the real issue here.  The real
issue is the policy not to use CL in Emacs packages; the warning about
the potential name conflicts and the byte compiler warning are just
the corollary.  So building the argument on those warning being
harmful is not gonna win the day, either.

Re: un-deprecating CL

[Richard Stallman]

We often add functions to the standard Emacs name space.  Often we add
individual CL facilities to it.  If the function has a simple name,
which doesn't start with the name of its Lisp program, that function
should be documented in the Emacs Lisp Reference Manual.

I don't like the idea of documenting all the CL facilities there.  I
don't want to declare them standard without documenting them, either.

An additional reason why I don't want to make them standard parts of
Emacs Lisp is that the CL style of calling conventions does not really
fit with the spirit of Emacs Lisp.

Thus, CL is available for users to use, but not a standard part
of the name space.

One possible alternative is to define these functions with a cl-
prefix, and for callers to use that prefix.  That gets rid of the
namespace issue.  And if we think of them as internal parts of
some Lisp package, they would not have to be in the Lisp Manual.

The only remaining drawback would be that code which uses them may be
somewhat harder to understand, for many users, because they will
use constructs not in the Lisp Manual.

That drawback exists now for the CL macros in programs that load CL at
compile time.  Perhaps the right thing is to move several commonly
used CL constructs into the standard namespace and document them
in the manual.

Re: un-deprecating CL

[Leo]

On 2007-09-15 19:06 +0100, Richard Stallman wrote:
> Perhaps the right thing is to move several commonly used CL constructs
> into the standard namespace and document them in the manual.

What are commonly used CL constructs? Is there a list of those
constructs?

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

>>>                                                  I use GNU Emacs
>>>                               http://www.gnu.org/software/emacs/

Re: un-deprecating CL

[Eli Zaretskii]

> From: Leo <sdl.web@gmail.com>
> Date: Sat, 15 Sep 2007 19:14:39 +0100
> 
> What are commonly used CL constructs? Is there a list of those
> constructs?

CL is documented in a separate manual, which comes with Emacs.

Re: un-deprecating CL

[Joe Wells]

Richard Stallman <rms@gnu.org> writes:

> Perhaps the right thing is to move several commonly used CL
> constructs into the standard namespace and document them in the
> manual.

I nominate the following constructs.

Extremely useful:

  incf callf callf2 setf function* destructuring-bind case typecase
  loop union intersection set-difference subst sort* delete*

Useful:

  pushnew adjoin caaar caaddr caadr cadaddr cadar caddar cadddr caddr
  cdaar defun* flet every substitute find subsetp

I suppose also someone should check whether the definitions in CL of
these are the same as the non-CL Emacs definitions (and if so delete
the ones in CL, otherwise somehow merge the functionality):

  pop push dolist caar cadr cdar cddr

-- 
Joe

Re: un-deprecating CL

[martin rudalics]

> I suppose also someone should check whether the definitions in CL of
> these are the same as the non-CL Emacs definitions (and if so delete
> the ones in CL, otherwise somehow merge the functionality):
> 
>   pop push dolist caar cadr cdar cddr

dotimes declare

Re: un-deprecating CL

[Richard Stallman]

    dotimes declare

`dotimes' is already supported.

How is CL `declare' useful in Emacs Lisp?

Re: un-deprecating CL

[martin rudalics]

 >     dotimes declare
 >
 > `dotimes' is already supported.
 >
 > How is CL `declare' useful in Emacs Lisp?

The above was in response to Joe Wells' remark

 >> I suppose also someone should check whether the definitions in CL of
 >> these are the same as the non-CL Emacs definitions (and if so delete
 >> the ones in CL, otherwise somehow merge the functionality):
 >>
 >>   pop push dolist caar cadr cdar cddr

All these (as well as `dotimes' and `declare') create the following
problem: When I eval a buffer containing an

(eval-when-compile (require 'cl) ...)

and subsequently invoke C-h f on one of these macros, I'm told that they
are Lisp macros in cl-macs.elc or cl.elc.  This is annoying because
their doc-strings may differ frequently - the cl-macs.el version of
`declare' doesn't have a doc-string at all.  Obviously, `find-function'
will get me to the cl-macs.el/cl.el versions as well.

Re: un-deprecating CL

[T. V. Raman]

I'd add to your excellent list the following:

some every notany 
remove-if delete-if 


>>>>> "Joe" == Joe Wells <jbw@macs.hw.ac.uk> writes:
    Joe> Richard Stallman <rms@gnu.org> writes:
    >> Perhaps the right thing is to move several commonly used
    >> CL constructs into the standard namespace and document
    >> them in the manual.
    Joe> 
    Joe> I nominate the following constructs.
    Joe> 
    Joe> Extremely useful:
    Joe> 
    Joe>   incf callf callf2 setf function* destructuring-bind
    Joe> case typecase loop union intersection set-difference
    Joe> subst sort* delete*
    Joe> 
    Joe> Useful:
    Joe> 
    Joe>   pushnew adjoin caaar caaddr caadr cadaddr cadar caddar
    Joe> cadddr caddr cdaar defun* flet every substitute find
    Joe> subsetp
    Joe> 
    Joe> I suppose also someone should check whether the
    Joe> definitions in CL of these are the same as the non-CL
    Joe> Emacs definitions (and if so delete the ones in CL,
    Joe> otherwise somehow merge the functionality):
    Joe> 
    Joe>   pop push dolist caar cadr cdar cddr
    Joe> 
    Joe> -- Joe
    Joe> 
    Joe> 
    Joe> _______________________________________________
    Joe> Emacs-devel mailing list Emacs-devel@gnu.org
    Joe> http://lists.gnu.org/mailman/listinfo/emacs-devel

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

Re: un-deprecating CL

[Richard Stallman]

    some every notany 
    remove-if delete-if 

Those are useful operations, and I would like to add facilities to do
them.  However, I don't like the CL functions because of their CL
style keyword argument, which I feel conflicts with the spirit of
Emacs Lisp.

Thus, I would rather add other facilities with simpler interfaces
to do these things.

Instead of `remove-if', there could be a macro `filter',
like `dolist' except that the body says whether to keep
an element or discard it.

Another macro could be designed to replace `some', `every' and
`notany'.

These macros would also run faster than those function calls,
for whatever that is worth.

Re: un-deprecating CL

[Johan Bockgård]

Richard Stallman <rms@gnu.org> writes:

>     some every notany 
>     remove-if delete-if 
>
> Those are useful operations, and I would like to add facilities to do
> them.  However, I don't like the CL functions because of their CL
> style keyword argument, which I feel conflicts with the spirit of
> Emacs Lisp.

FWIW, some, every, notany (and notevery) don't use keyword arguments.


Here are a few other things

  * Make `=', `/=', `<', '<=' etc take a &rest argument (they do in
    XEmacs). "The value of < is true if the numbers are in monotonically
    increasing order; otherwise it is false." This is actually useful.

  * Make mapcar take a &rest arg (i.e it should do what mapcar* does
    now).

-- 
Johan Bockgård

Re: un-deprecating CL

[Richard Stallman]

      * Make `=', `/=', `<', '<=' etc take a &rest argument (they do in
	XEmacs). "The value of < is true if the numbers are in monotonically
	increasing order; otherwise it is false." This is actually useful.

      * Make mapcar take a &rest arg (i.e it should do what mapcar* does
	now).

These changes are ok to install, as long as you update the Emacs Lisp
manual while you're at it.  As natural extensions, they don't cost
much in terms of increasing the complexity of Emacs Lisp.

Re: un-deprecating CL

[Stefan Monnier]

>       * Make `=', `/=', `<', '<=' etc take a &rest argument (they do in
> 	XEmacs). "The value of < is true if the numbers are in monotonically
> 	increasing order; otherwise it is false." This is actually useful.

>       * Make mapcar take a &rest arg (i.e it should do what mapcar* does
> 	now).

> These changes are ok to install, as long as you update the Emacs Lisp
> manual while you're at it.  As natural extensions, they don't cost
> much in terms of increasing the complexity of Emacs Lisp.

On the other hand, they may come at a performance cost and have very
little use.


        Stefan

Re: un-deprecating CL

[Richard Stallman]

    > These changes are ok to install, as long as you update the Emacs Lisp
    > manual while you're at it.  As natural extensions, they don't cost
    > much in terms of increasing the complexity of Emacs Lisp.

    On the other hand, they may come at a performance cost and have very
    little use.

Comparison are open-coded by the compiler, so this will require a compiler
change but won't cause any performance penalty.

As for mapcar, it is pretty slow already, and the main cost is in
calling the user's function.  That won't get any slower.

Re: un-deprecating CL

[Stefan Monnier]

> As for mapcar, it is pretty slow already, and the main cost is in
> calling the user's function.  That won't get any slower.

Then again: how many uses of mapcar* have you encountered?
If you object to `union' because it's not used often, I'd expect you to
reject the vararg version of mapcar.


        Stefan

Re: un-deprecating CL

[Johan Bockgård]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> Then again: how many uses of mapcar* have you encountered?

I found these. Someone might want to fix them.

lisp/calc/calcalg3.el:   (mapcar* 'calcFunc-div
lisp/calc/calc-nlfit.el: (let* ((ratios (mapcar* 'math-div pdata qdata))
lisp/calc/calc-nlfit.el: (newparms (mapcar* 'math-add (copy-tree parms) zeta))
lisp/calc/calc-nlfit.el: (mapcar* (lambda (x y) (list 'sdev x y)) finalparms sigmas)
lisp/calc/calc-nlfit.el: (poverqdata (mapcar* 'math-div pdata qdata))
lisp/erc/erc.el:         (mapcar* (lambda (prop value)

-- 
Johan Bockgård

Re: un-deprecating CL

[Richard Stallman]

    > As for mapcar, it is pretty slow already, and the main cost is in
    > calling the user's function.  That won't get any slower.

    Then again: how many uses of mapcar* have you encountered?
    If you object to `union' because it's not used often, I'd expect you to
    reject the vararg version of mapcar.

The issues are not similar.  One is adding a new function.
The other is a simple, natural extension in an existing function.
The former costs more, in complexity.

Re: un-deprecating CL

[Richard Stallman]

    FWIW, some, every, notany (and notevery) don't use keyword arguments.

In that case, I don't object to adding them.  But I still think
that the macro I suggested would be better for actual use.

Re: un-deprecating CL

[T. V. Raman]

Additional cl functions that would be nice to have:
first, second and friends.

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

Re: un-deprecating CL

[Richard Stallman]

    Additional cl functions that would be nice to have:
    first, second and friends.

Those clearly add no capabilities to Emacs;
they only add more facts to remember.

Re: un-deprecating CL

[Richard Stallman]

      incf callf callf2 setf function* destructuring-bind case typecase
      loop union intersection set-difference subst sort* delete*

That is a long list.

destructuring-bind is ok to add, because it is simple and modular.
Likewise `case' and `typecase'.

I don't want to add CL argument lists, so no `function*' or `defun*'.

I don't want to add `union' or `intersection' or `set-difference' or
`subst' or `sort*' or `delete*', because they use CL keyword
arguments.

Adding `setf' really means adding `defstruct'.  That might be a good
feature to add, but it is too complex because of all the structure
options.  If we get rid of most of them, `defstruct' could be simple
enough to add.

`incf' and `callf' are creeping featurism, and not worth adding.
`setf' is enough.  But I would not mind extending `push' and `pop'
work with structs in the CL fashion.

      pushnew adjoin caaar caaddr caadr cadaddr cadar caddar cadddr caddr
      cdaar defun* flet every substitute find subsetp

`pushnew' is ok.  `caaar' and so on are superfluous, I think.
Definitely not `flet'; I think its use is bad practice.

`every', `substitute', `find' and `subsetp' have the ugly CL keyword
arguments, so I don't want to add them.

Re: un-deprecating CL

[Joe Wells]

Richard Stallman <rms@gnu.org> writes:

>       incf callf callf2 setf function* destructuring-bind case typecase
>       loop union intersection set-difference subst sort* delete*
>
> That is a long list.

But also a good list.

> destructuring-bind is ok to add, because it is simple and modular.

By the way, destructuring-bind supports full Common Lisp style
argument lists.

> Likewise `case' and `typecase'.

Hurray!  These two macros are extremely useful.

> I don't want to add CL argument lists,

Just curious: Why not?

(By the way, librep, which is derived from the GNU Emacs Lisp
implementation, implements keyword arguments, optional arguments with
defaults, and dotted-list notation for &rest arguments.  It doesn't
implement all the possibilities of CL.)

> so no `function*' or `defun*'.

> I don't want to add `union' or `intersection' or `set-difference' or
> `subst' or `sort*' or `delete*', because they use CL keyword
> arguments.

Okay, but they are extremely useful functions, and people keep
reimplementing this functionality.

For example, typing “C-h a union RET” in my running Emacs reveals
union (from cl), gnus-union and gnus-sorted-union, ediff-union, and
jbw-sorted-number-list-union (my own).  And I wouldn't be surprised to
find other packages (which I haven't loaded in this Emacs) that also
implement union.

> Adding `setf' really means adding `defstruct'.

By the way, setf and related functions are very useful even without
defstruct.  It's the “generalized variable” notion which makes them
useful.  Here are some examples of using “generalized variables” from
my code that don't rely on defstruct:

  (setf (cadr break-style) 'line)
  (setf (nth 1 node) (cons (cons 'id unique-id) (nth 1 node)))

  (callf2 delete macro (cadr p))
  (callf2 concat "[" (car return-value) "]")

  (push x (symbol-value tab))
  (push ":active" (cdr (assq 'class munged)))

  (pushnew macro (cadr p) :test #'equal)

Writing out the macroexpanded versions of the above would be a pain.

I can also supply examples using structures.  I'm just pointing out
that the “generalized variable” notion is about more than structures.

> That might be a good
> feature to add, but it is too complex because of all the structure
> options.  If we get rid of most of them, `defstruct' could be simple
> enough to add.

I did forget to ask for defstruct!  So yes, defstruct also please.

> `incf' and `callf' are creeping featurism, and not worth adding.

callf is marvelous and makes it much easier to program!

I'd hate to have to define my own callf all the time.

> `setf' is enough.  But I would not mind extending `push' and `pop'
> work with structs in the CL fashion.
>
>       pushnew adjoin caaar caaddr caadr cadaddr cadar caddar cadddr caddr
>       cdaar defun* flet every substitute find subsetp
>
> `pushnew' is ok.  `caaar' and so on are superfluous, I think.
> Definitely not `flet'; I think its use is bad practice.
>
> `every', `substitute', `find' and `subsetp' have the ugly CL keyword
> arguments, so I don't want to add them.

Nonetheless, the functions are very useful.

Richard Stallman <rms@gnu.org> writes:

>     some every notany
>     remove-if delete-if
>
> Those are useful operations, and I would like to add facilities to do
> them.

I'm very happy to hear this, because it is tiring to reimplement and
redebug such functionality.

I hope this message is helpful.

-- 
Joe

Re: un-deprecating CL

[Richard Stallman]

    > destructuring-bind is ok to add, because it is simple and modular.

    By the way, destructuring-bind supports full Common Lisp style
    argument lists.

I don't mind having some of this in that special construct, but I am
not sure we should document all of the features.

    > I don't want to add CL argument lists,

    Just curious: Why not?

It is added complexity that we don't need.  To add them to standard
Emacs Lisp functions would call for documenting them with great
importance.  To have the alternative constructs `function*' and
`defun*' is kludgy.

It is one thing to have `function*' and `defun*' in a compatibility
package.  It is quite another to give them legitimacy in Emacs Lisp.

    For example, typing ?C-h a union RET? in my running Emacs reveals
    union (from cl), gnus-union and gnus-sorted-union, ediff-union, and
    jbw-sorted-number-list-union (my own).  And I wouldn't be surprised to
    find other packages (which I haven't loaded in this Emacs) that also
    implement union.

The fact that Gnus and ediff want a union function is not enough
reason to add one as an Emacs feature.  In fact, there are four
packages in Emacs that define a union function.  I don't think that is
enough to justify adding one _and documenting it_.  It would take
considerably more reason.

      (callf2 delete macro (cadr p))
      (callf2 concat "[" (car return-value) "]")

I find callf and callf2 extremely counterintuitive, and I would rather
people write that code with setf.

Re: un-deprecating CL

[David O'Toole]

Richard Stallman <rms@gnu.org> writes:

> It is added complexity that we don't need.  To add them to standard
> Emacs Lisp functions would call for documenting them with great
> importance. 

But defcustom, make-hash-table, define-derived-mode,
make-network-process, etc all use keyword arguments as far as I can
tell. 

It isn't clear to me what you mean by "documenting them with great
importance."

> It is one thing to have `function*' and `defun*' in a compatibility
> package.  It is quite another to give them legitimacy in Emacs Lisp.

For whatever it's worth, I would not describe CL as a compatibility
package. The manual's overview says that it is designed to make Emacs
Lisp programming more convenient. (The part on porting Common Lisp
code is Appendix D.)

-- 
David O'Toole 
dto@gnu.org
http://dto.freeshell.org/notebook/

Re: un-deprecating CL

[Richard Stallman]

    > It is added complexity that we don't need.  To add them to standard
    > Emacs Lisp functions would call for documenting them with great
    > importance. 

    But defcustom, make-hash-table, define-derived-mode,
    make-network-process, etc all use keyword arguments as far as I can
    tell. 

That's not cogent.  The fact that one part of the system is complex is
no reason to make another part unnecessarily complex.

If you want to understand my decision, the crucial point is that I consider
the complexity of these functions a negative.

    It isn't clear to me what you mean by "documenting them with great
    importance."

We would have to spend a lot of text and attention on documenting them
if they were in such a central place in the language.

Re: un-deprecating CL

[Lennart Borgman (gmail)]

Richard Stallman wrote:
>     > It is added complexity that we don't need.  To add them to standard
>     > Emacs Lisp functions would call for documenting them with great
>     > importance. 
> 
>     But defcustom, make-hash-table, define-derived-mode,
>     make-network-process, etc all use keyword arguments as far as I can
>     tell. 
> 
> That's not cogent.  The fact that one part of the system is complex is
> no reason to make another part unnecessarily complex.
> 
> If you want to understand my decision, the crucial point is that I consider
> the complexity of these functions a negative.

If the keyword argument handling is broken out and generalized will it 
still add much complexity? (This could be combined with making a 
recommendation not to use that functionality normally.)

Re: un-deprecating CL

[Richard Stallman]

    If the keyword argument handling is broken out and generalized will it 
    still add much complexity?

The complexity that bothers me is the complexity of the programming
interface.  This is not about implementation.

Re: un-deprecating CL

[David O'Toole]

Richard Stallman <rms@gnu.org> writes:

>     If the keyword argument handling is broken out and generalized will it 
>     still add much complexity?
>
> The complexity that bothers me is the complexity of the programming
> interface.  This is not about implementation.

I don't understand what is complicated about the programming interface
of keyword arguments.

-- 
David O'Toole 
dto@gnu.org
http://dto.freeshell.org/notebook/

Re: un-deprecating CL

[Richard Stallman]

    > The complexity that bothers me is the complexity of the programming
    > interface.  This is not about implementation.

    I don't understand what is complicated about the programming interface
    of keyword arguments.

I've done all I can to explain my decision.
We may just see these things differently.

Re: un-deprecating CL

[David O'Toole]

Richard Stallman <rms@gnu.org> writes:

>     > The complexity that bothers me is the complexity of the programming
>     > interface.  This is not about implementation.
>
>     I don't understand what is complicated about the programming interface
>     of keyword arguments.
>
> I've done all I can to explain my decision.
> We may just see these things differently.

Okay :-). I hope I have not been too much of a pest, I just felt
strongly about it.

-- 
David O'Toole 
dto@gnu.org
http://dto.freeshell.org/notebook/

Re: un-deprecating CL

[David O'Toole]

Richard Stallman <rms@gnu.org> writes:

> destructuring-bind is ok to add, because it is simple and modular.
> Likewise `case' and `typecase'.
>
> I don't want to add CL argument lists, so no `function*' or `defun*'.

Destructuring-bind supports most of the CL argument list stuff,
including keyword arguments; this makes it simple to implement
functions that take keyword arguments, and might encourage people to
do so.

> I don't want to add `union' or `intersection' or `set-difference' or
> `subst' or `sort*' or `delete*', because they use CL keyword
> arguments.

--snip--

> `every', `substitute', `find' and `subsetp' have the ugly CL keyword
> arguments, so I don't want to add them.

It isn't clear to me what exactly is so bad about keyword arguments,
or what alternative (if any) you have in mind for dealing sensibly
with functions accepting more than one or two optional arguments. When
you want to supply `x' as just one of the optional arguments to a
function that takes several, and the one you want to supply happens
not to be the first, you end up writing things like 

(foo bar nil nil nil x)

I cringe when I have to do this. Furthermore, if the defaults are not
`nil' then you also have to look up what are acceptable values to pass
for the arguments that you did not want to specify in the first
place. For example, `make-hash-table' would arguably be harder to use
if did not employ keyword arguments, of which it takes five---and
several of the defaults are non-nil.

Speaking of which, why is it ok for a frequently-used built-in
function like make-hash-table to use keyword arguments in the first
place?

> Adding `setf' really means adding `defstruct'.  That might be a good
> feature to add, but it is too complex because of all the structure
> options.  If we get rid of most of them, `defstruct' could be simple
> enough to add.

I don't understand---defstruct is already implemented in the CL
package. Are you talking about copying that definition, removing many
of the options, and then pasting it somewhere else?

-- 
David O'Toole 
dto@gnu.org
http://dto.freeshell.org/notebook/

Re: un-deprecating CL

[Richard Stallman]

    > Adding `setf' really means adding `defstruct'.  That might be a good
    > feature to add, but it is too complex because of all the structure
    > options.  If we get rid of most of them, `defstruct' could be simple
    > enough to add.

    I don't understand---defstruct is already implemented in the CL
    package. Are you talking about copying that definition, removing many
    of the options, and then pasting it somewhere else?

Yes, exactly.

I would be glad to add a simple defstruct construct, but the
complexity of the defstruct construct as now implemented in CL is too
much.  CL is a compatibility package, and it was written with a view
towards supporting as much as possible of Common Lisp functionality.
That is a fine goal for a compatibility package, but it is the wrong
goal for designing Emacs Lisp, and I will not let it creep in merely
because we would like to have some kind of defstruct.

Thus, I am looking for a solution that adds a simple defstruct
construct to Emacs Lisp.

We could code it so that there is a stub for CL to redefine so as to
implement all those structure options.  Thus, programs which load
CL could still use them, and we would not have much duplicated code.
But they wouldn't be part of standard Emacs Lisp itself.

Re: un-deprecating CL

[Richard Stallman]

    > `every', `substitute', `find' and `subsetp' have the ugly CL keyword
    > arguments, so I don't want to add them.

    It isn't clear to me what exactly is so bad about keyword arguments,
    or what alternative (if any) you have in mind for dealing sensibly
    with functions accepting more than one or two optional arguments.

The fact that they accept so many optional arguments is one thing I
don't like about them.  It is too much complexity.  If you showed me
lots of places that wanted to call a simple `union' function, I'd say
sure.  But adding a CL-style `union' function is another story.

Re: un-deprecating CL

[Johan Bockgård]

David O'Toole <dto@gnu.org> writes:

> Furthermore, if the defaults are not `nil' then you also have to look
> up what are acceptable values to pass for the arguments that you did
> not want to specify in the first place.

But in Emacs Lisp (unlike CL) optional arguments always default to nil.

-- 
Johan Bockgård

Re: un-deprecating CL

[David O'Toole]

Richard Stallman <rms@gnu.org> writes:

> One possible alternative is to define these functions with a cl-
> prefix, and for callers to use that prefix.  That gets rid of the
> namespace issue.  And if we think of them as internal parts of
> some Lisp package, they would not have to be in the Lisp Manual.

Would it be possible to use compiler macros so that existing programs
could continue to use these functions' un-prefixed names at compile
time?

> That drawback exists now for the CL macros in programs that load CL at
> compile time.  Perhaps the right thing is to move several commonly
> used CL constructs into the standard namespace and document them
> in the manual.

That would be helpful but it would still prevent many programs from
being contributed.

-- 
David O'Toole 
dto@gnu.org
http://dto.freeshell.org/notebook/

Re: un-deprecating CL

[Richard Stallman]

    > One possible alternative is to define these functions with a cl-
    > prefix, and for callers to use that prefix.  That gets rid of the
    > namespace issue.  And if we think of them as internal parts of
    > some Lisp package, they would not have to be in the Lisp Manual.

    Would it be possible to use compiler macros so that existing programs
    could continue to use these functions' un-prefixed names at compile
    time?

That would be possible, but it seems like a bad idea -- it would
confuse people reading the program.  Writing the calls with `cl-'
would be a clearer practice.

    That would be helpful but it would still prevent many programs from
    being contributed.

"Prevent" is too strong a word.  These programs would need some change
in order to be installed in Emacs.

Adding `cl-' in front of certain function names is a pretty easy
change to make; we could add a command like query-replace to do it
semiautomatically.

Re: un-deprecating CL

[David O'Toole]

Eli Zaretskii <eliz@gnu.org> writes:

>     In my opinion, the best way to program Emacs Lisp is to use the many,
>     many powerful macros and functions of the CL package.
>
> This basically says that the author is already sold on using CL as
> heavily as possible, and therefore all the rest of the essay is
> suspect of trying to sell the same idea to the reader.

Selling CL to the reader is not the point of the essay at all. I
openly labeled my opinions as such and there is therefore is no reason
to "suspect" the essay of anything.

> Granted, a blog isn't required to present a convincing argument.  But
> if this essay does need to convince me, it will have to do a lot
> better.  For example, I would like to hear about disadvantages of
> using CL, not just about how wonderful it is.  IOW, a convincing
> argument will present a balanced view of the issue, and try to win by
> showing that the balance is in its favor.

Although I did make it clear that I find the CL package very useful,
my point in this was to motivate my subsequent discussion of the CL
policy, and explain to the reader my underlying motivations for
thinking the CL policy is harmful. These opening paragraphs also place
the issue in context for those readers who may not know about the CL
compatibility package, or who may know about it but have been
discouraged by the policy from looking into it further. (*) see below

I was writing about two separate issues: the rationale for the CL
policy (which I find less than compelling) and what I see as the
deleterious effects of the policy on Emacs. You missed both, and seem
to think my essay was designed to make people adopt Common Lisp
(i.e. wanting me to discuss disadvantages of CL, etc.) The essay's
title, and the fact that I spend most of the essay talking about the
CL policy and not CL itself, should make this clear enough.

A full discussion of the pros and cons of Common Lisp usage, or
exploring the "large language versus small language" debate, is
outside the scope of my essay, and probably best left to Wikipedia.

> to the warning in the manual and the byte compiler, I hope you
> realize that the name conflict is not the real issue here.  The real
> issue is the policy not to use CL in Emacs packages; the warning about
> the potential name conflicts and the byte compiler warning are just
> the corollary.  So building the argument on those warning being
> harmful is not gonna win the day, either.

It should be obvious that I know that these warnings are the result of
the policy. That is why I mentioned them in a post whose main subject
was the policy.

(If you are saying that the name conflict issue is only a "corollary"
of the policy and not the main reason for it, then what is the reason
for the policy?)

Perhaps I am to blame for not revising the post and increasing its
clarity but someone else posted it here before I got a chance to
improve it. 

 (*) Despite what people say about still being able to use the macros
while complying with the policy, in my opinion the policy is still a
discouragement. You have to memorize which of its features you must
abstain from using (and therefore lose the benefit of those features)
if you are to have any hope of someday contributing Lisp code to GNU
Emacs.

This last point is what I am really getting at in my criticism of the
policy. I was asked to contribute two of my programs, both of which
make heavy use of the CL package and total upwards of 7,000 lines. I
am more than willing to assign them, and I already have Emacs papers
on file with the FSF; but it's clear now that these programs cannot be
accepted, because they use many CL functions. Furthermore I am not
willing to make such changes as would make them acceptable---it would
not improve the programs (probably the opposite) and as I argued
before, I would likely have to reimplement my own (possibly incorrect)
versions of the functions I want, at some expense in time and effort.

This has relatively little impact on me, but Emacs will lack two
packages that a maintainer had considered worth including. Maybe this
outcome doesn't bother you because you don't personally find my work
exciting, but it is ironic because the undesirability of this scenario
(i.e. the FSF not being able to include packages with Emacs that it
considers useful and appropriate) was adduced as an argument against
ELPA, and is clearly an important concern for the maintainers. But
that harm, only conjectural in the ELPA discussion, has already
resulted from the CL policy. It tells me years ahead of time that I
cannot contribute code to Emacs unless I eschew tools that are
powerful and readily understood by anyone familiar with Common Lisp,
and that are included in the standard Emacs distribution (yet are
somehow non-standard). Instead I must deliberately write programs in a
style I consider less expressive and less convenient and less
enjoyable, which I am not going to do. And I think some other cl.el
users will feel the same, despite how much they would like to improve
Emacs. If the use of the CL package were to become more widespread
(for example if someone writes a widely-read and translated tutorial
like the one I wrote for org-mode) there would be a larger body of
code that Emacs could not include, and the harm the policy causes
would then become more obvious.

To sum up: hypothetical bad things (name conflicts that can only be
created by people who are not using a package-specific prefix, and
thus not following the guidelines anyway) are said to justify a policy
which creates *real* bad things (Emacs maintainers having to reject
perfectly good packages because they invoke other Emacs functions
whose names are effectively reserved) and I do not see the sense in
it.

By pointing this out I hope it will encourage us to overcome such
issues as which manual a function is supposed to be documented in if
it lacks a package-specific prefix and just find a solution.

If the real issue is the Emacs maintainers not wanting to maintain or
debug programs that use the CL functions, that would be quite
understandable. But then put that in the manual, and not the argument
about name conflicts.

-- 
David O'Toole 
dto@gnu.org
http://dto.freeshell.org/notebook/

Re: un-deprecating CL

[Eli Zaretskii]

> From: David O'Toole <dto@gnu.org>
> Date: Sun, 16 Sep 2007 17:46:37 -0400
> 
> (If you are saying that the name conflict issue is only a "corollary"
> of the policy and not the main reason for it, then what is the reason
> for the policy?)

I don't think it's a good idea for me to explain a policy that isn't
mine.  I think Richard at least hinted at his reasons in a recent
message in this thread.