[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: CL package serious deficiencies

From: egnarts-ms
Subject: RE: CL package serious deficiencies
Date: Tue, 7 Feb 2012 04:29:15 -0800 (PST)

Drew Adams wrote:
> 2. There are lots of people who use cl.el.  There are even lots of people
> who
> systematically write libraries that depend on cl.el functions at runtime
> (not
> just macros at compile time).  Unfortunately.  My impression is that this
> might
> be increasingly the case, and that perhaps younger or newer Emacs users
> are more
> likely to do so.

As I have pointed out in the original post, I have managed to fix all the
points described there.  (Except for `incf', `decf' etc. -- I just
introduced new, correct variants like `incf*', `decf*').  So I am eager to
share my experience.. although I realize that my experience with Emacs is
relatively poor.  And what is the most annoying thing, to my mind, is an
absence of understanding of interdependencies between different
parts/libs/files of Emacs during the build process.  I just don't know what
piece of functionality it is possible to use when implementing another piece
of functionality.

> 4. And yes, it's non-trivial work to get things right.  If you, Stefan,
> find the
> existing code too lightly commented and less than clear, then it should be
> evident that others will too.

You know, in my opinion the code of CL package is quite understandable
(especially in comparison with commercial C++ outsource code I'm working
with) :)

And what kills me the most, is that I cannot manage to find a true Lispy
code.  Yes, I'm inexperienced lisper and maybe I just don't understand
something.  But what I saw in CL and some other places of Emacs sources
(lisp-mode.el for example) is not true Lispy code in the sense that it
doesn't attempt to make use of the main Lisp advantage -- ability to create

To be more specific, now that I read about anaphoric macros in "On Lisp" by
Paul Graham, I find it awkward not to use that functionality in complicated
code containing lots of conditioning.  Moreover, I created something that is
called "aif-op-1" -- a macro that works like this:

(aif-op-1 (eq (func-1)
    ;; here we have (func-1) result accessible with "it" name
    (func-2 arg1 it)
  ;;here we also have "it" bound to what previous (func-1) returned
  (func-3 it)

Such things are not difficult to implement in Elisp.  But I haven't seen
anything like these neat language tricks in Emacs sources, especially in CL
package.  Instead, much code is just written manually rather than
automatically (by macros).

> 5. IMO it makes sense to proceed gradually, and to start by including more
> of
> the simpler things that do work well, even if in a limited way, into
> regular
> Emacs Lisp.

This is a good idea.  We must try to make basic Lisp ideas be viable and
working, and have them evolve and develop in the modern world.  Elisp is a
good language for what it is used.  We must make it excellent.
View this message in context: 
Sent from the Emacs - Dev mailing list archive at Nabble.com.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]