On Tue, Feb 09, 2010 at 01:42:13AM -0500, Jason Spiro wrote:
On Sun, Jan 3, 2010 at 9:58 PM, Stephen Bach <[email protected]> wrote:
On Sat, Jan 02, 2010 at 10:40:10PM -0500, Jason Spiro wrote:
3. GNU Emacs enforces the backward policy that packages must not use cl.el Common Lisp extensions at runtime. This kind of restriction is another enemy to development momentum; if it's expedient to Vegard or another developer to leverage a standard library, they should be empowered to do so.
But John J. Foerch said in his email of Wed, Oct 3, 2007 at 11:00 PM at http://my-trac.assembla.com/vimpulse/ticket/2 that there are cl.el macros that override core Emacs functions. Do you still stand by your assertion?
Yes. cl.el's version of push subsumes GNU Emacs' standard push - it's not dangerous. Almost anyone who uses Emacs extensively will load cl.el as part of their configuration. XEmacs loads it by default.
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. :)
Two cents: I think the cl.el policy is smart, actually. Common Lisp is a rather crufty language --- a design of "politics" rather than a design of "art" as the old cliché about CL vs. Scheme goes. For example, it would be hard to make the case that generalized variables belong in Elisp, as they are unnecessary, redundant, and complex. Don't get me wrong, I love Common Lisp for what it is, on its own terms, but I would not hold it up as some kind of ideal for the future improvement of Emacs Lisp. What I would advocate for (and have) is to add specific useful features to Elisp in the specific areas where Elisp is lacking. For a single example, Elisp has no fold or reduce, and I have found need to write it myself on more than on occasion. Anyway, my basic point is that if you want to see Elisp improved, there are more elegant languages than Common Lisp to use as your model. -- John Foerch