1 Apr 2009 03:01
Re: elisp's cl package. Don't understand the notice about eval-when-compile
Miles Bader <miles <at> gnu.org>
2009-04-01 01:01:56 GMT
2009-04-01 01:01:56 GMT
"Thomas F. Burdick" <tburdick <at> gmail.com> writes: > 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(Continue reading)... > 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. The problem with cl.el is that it's a giant glutinous mess, that seems to offer the vague promise to be kinda-like-common-lisp, but really isn't (it can't be, the elisp core cannot support much of common-lisp efficiently), and as a result is kind of misleading to users (especially to common-lisp users, who might think "oh great, I can just use common-lisp!" ... hahaha, sorry bub...). I agree that many _parts_ of cl.el are quite good, and useful, but while you may be able to pick and choose wisely, I think many users aren't as skillful, and would end up using the horrible grotty bits as well -- and we really don't want to increase the number of dependencies on horrible grotty things. Personally, I'd use a different tactic for addressing this problem -- I'd try to split out the useful parts into separate packages (maybe a "setf" package, a "struct" package, a "sequence" package etc), and pull the best and simplest bits into core elisp -- but rms's approach is at least simple and easy.
...
> 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.
The problem with cl.el is that it's a giant glutinous mess, that seems
to offer the vague promise to be kinda-like-common-lisp, but really
isn't (it can't be, the elisp core cannot support much of common-lisp
efficiently), and as a result is kind of misleading to users (especially
to common-lisp users, who might think "oh great, I can just use
common-lisp!" ... hahaha, sorry bub...).
I agree that many _parts_ of cl.el are quite good, and useful, but while
you may be able to pick and choose wisely, I think many users aren't as
skillful, and would end up using the horrible grotty bits as well -- and
we really don't want to increase the number of dependencies on horrible
grotty things.
Personally, I'd use a different tactic for addressing this problem --
I'd try to split out the useful parts into separate packages (maybe a
"setf" package, a "struct" package, a "sequence" package etc), and pull
the best and simplest bits into core elisp -- but rms's approach is at
least simple and easy.


RSS Feed