emacs-devel
[Top][All Lists]
Advanced

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

Re: CL package serious deficiencies


From: Nix
Subject: Re: CL package serious deficiencies
Date: Tue, 07 Feb 2012 21:23:55 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.93 (gnu/linux)

On 7 Feb 2012, Lennart Borgman spake thusly:

> On Tue, Feb 7, 2012 at 22:10, Nix <address@hidden> wrote:
>>> But no one has said that cl.el should not be used. I have not seen any
>>> problems when the instructions for its use are followed.
>>
>> Since those instructions amount to 'don't use it except at compile-
>> time', this is not incredibly surprising.
>
> I think you are misundering.. ;-) -- or am I misunderstanding you...
>
> The code that uses cl.el must be compiled. Is that a very sever limitation?

Er, yeah, it's that you can't do

(require 'cl)

without getting moaned at by the byte-compiler and rejected from
inclusion into Emacs, a limitation true of no other elisp package in
existence (not even apel, which really *did* break things back in the
day, perhaps because it was last maintained in 1996).

Yeah, you can do

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

or

(require 'cl-macs)

but those do not do the same thing.

So as a result, if one of us wants to use `cadr' in ordinary Lisp
functions that are part of Emacs, we can, but if we want to use `caddr',
we can't. Now does that restriction make any sense at all? I'd say it
doesn't: if there are bugs preventing the whole byte-compile-cl-warn
mess being dropped from bytecomp.el, then those bugs should be fixed.

(Obviously, `caddr' is hardly essential -- I used it only for rhetorical
purposes, becuase it is quite clear that it is no more reasonable to ban
its use at runtime than it is to ban use of 'car' -- but some things in
cl and especially cl-extra really are useful and pointless to
reimplement: random* for example, or the extra mapping functions.)

(FWIW, the *last* time I asked about this, many years ago, I was told
that runtime use of cl was out of the question because it used too much
memory. I presume that this argument is obsolete :) )

-- 
NULL && (void)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]