[implementations-list] GNU Emacs policy that says packages must not use cl.el at runtime

[Vegard Øye]

> From: jasonspiro3 at gmail.com
> Date: Tue, 9 Feb 2010 01:42:13 -0500
>
> What reason does the GNU Emacs team give for this policy? If it
> turns out to be a flimsy reason, then perhaps you or Vegard could
> get the policy changed if you wanted to. :)

I can think of one serious reason: macros don't debug well. For
example, evaluate the following old code in the *scratch* buffer:

    (require 'cl)

    (defun vimpulse-pm-is-real-match (pos1 pos2)
      (destructuring-bind
          ((class1 . match1) (class2 . match2))
          (list (syntax-after pos1) (syntax-after pos2))
        (or (eq match1 (char-after pos2))
            (eq match2 (char-after pos1))
            (eq match1 match2))))

Then move point inside the defun and hit C-u C-M-x, and you get the
following error message:

    edebug-syntax-error: Invalid read syntax: "Failed matching",
    ([&optional "&environment" arg] ...

There are rumors of moving some of cl.el's core into GNU Emacs,
presumably rewritten in a way which doesn't have this problem. It
would certainly be cool if standard Elisp became more CL-like. Heck,
some non-lispy languages are more CL-like than Elisp these days. :/

The removal of cl.el forms didn't really make much of a difference to
code size or readability, however. The function above was rewritten in
changeset [38] to use a `let' form instead of `destructuring-bind',
dismantling the arguments explicitly; it is one line longer than the
original. The other frequent cl.el form was `case', whose `cond'
replacement just does the comparison out in the open:
(eq variable 'this), (eq variable 'that), and so on. Although verbose,
it's usually the same number of lines, which is what I care about :)

We are approaching release. Has anyone tried the latest revisions?

Vegard
 		 	   		  
_________________________________________________________________
Få nye Windows Live™ Messenger.
http://download.live.com/messenger