Re: elisp's cl package. Don't understand the notice about eval-when-compile

["Thomas F. Burdick" <tburdick@gmail.com>]

On Mar 26, 3:12 am, Xah Lee <xah...@gmail.com> wrote:
> Xah Lee <xah...@gmail.com> writes:
> > > in emacs lisp's CL package documentation “(info "(cl)Overview")”, it
> > > has this passage:
>
> > >    *Please note:* the "CL" functions are not standard parts of the
> > > Emacs Lisp name space, so it is legitimate for users to define them
> > > with other, conflicting meanings.  To avoid conflicting with those
> > > user
> > > activities, we have a policy that packages installed in Emacs must not
> > > load "CL" at run time.  (It is ok for them to load "CL" at compile
> > > time
> > > only, with `eval-when-compile', and use the macros it provides.)  If
> > > you are writing packages that you plan to distribute and invite
> > > widespread use for, you might want to observe the same rule.
>
> > > I don't quite understand it.
>
> On Mar 25, 3:02 am, "Thomas F. Burdick" <tburd...@gmail.com> wrote:
>
> > No. It's saying that if you are trying to get your package included in
> > the official Emacs distribution, you can only use macros from cl.el,
> > not functions.
>
> Ok, after spent some 30 min starting to write a reply with much more
> confusion, i think i understand this now and i think this is the best
> explanation. Thanks.
>
> though, there's still the practical question of which ones are macros.
> There doesn't seem to have a clear list.
>
> basically, my concern here is practical one. I want to use some
> functionalities in cl, but need to know which i can use etc. So, if
> programers using cl for their packages for public, they need to have a
> list of exactly what they can use.

The Emacs maintainers have a really schizophrenic policy when it comes
to cl.el, and it's resulted in a mess. On the one hand, they
distribute a bunch of language extensions as part of the distribution.
On the other hand, they disapprove of the very package they
distribute, so they don't want any other bundled code to use it. So of
course the extensions run the range from nice, idiomatic things that
ought to be incorporated into elisp (support for places/setf, for
example), to very useful extensions like loop, to strange duplications
of existing functionality (concatenate?), to bizzare and horrible
ideas like lexical-let.

If you want your code incorporated into the official Emacs
distribution, I would avoid cl.el altogether. Or maybe use loop and
setf, but I'm not sure you can count on them always expanding into cl-
free code. The reason there's no good documentation about what you can
use is that the Emacs maintainers frown on the whole package. So as a
practical matter, avoid it.

If you just have an elisp package that you want to make publicly
available, I see no need to avoid cl.el. It's distributed with emacs,
so there's no reason not to use it. Just, stick to the tasteful
parts :-)

> ... after some 10 min thinking and reading the cl doc, at this point i
> guess i don't have a question... i guess a clear list of macro isn't
> there because the whole thing is rather complex... the cl package is
> rather more for CL programers coming to elisp as opposed to simply a
> extra library of useful functions...

It's both. I think RMS has an irrational hatred of CL, so there are a
lot of the useful things in cl.el that should have migrated into the
core elisp. As it is, they're ghettoized along with the parts of that
package that exist just as a crutch for Common Lispers.

>
> here's some more confusion i have...
>
> For example, when i do describe-function on “pop”, it says:
> «pop is a Lisp macro in `subr.el'.»
>
> but after loading cl, it says:
> «pop is a Lisp macro in `cl.el'.»
>
> So, it appears, cl package also shadow elisp symbols (apparantly they
> are the same thing, but if so, why there's one in still in cl when
> already moved to elisp?).
>
>   Xah
> ∑http://xahlee.org/
>
> ☄