From: [email protected] 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