From: egnarts-ms <egnartsms@gmail.com>
To: Emacs-devel@gnu.org
Subject: RE: CL package serious deficiencies
Date: Tue, 7 Feb 2012 04:29:15 -0800 (PST) [thread overview]
Message-ID: <33278223.post@talk.nabble.com> (raw)
In-Reply-To: <A7B2B1DBEE8848489E9B54E74B64F8A1@us.oracle.com>
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
DSLs.
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)
'symbol)
;; 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: http://old.nabble.com/CL-package-serious-deficiencies-tp33271707p33278223.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.
next prev parent reply other threads:[~2012-02-07 12:29 UTC|newest]
Thread overview: 104+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-06 14:18 CL package serious deficiencies egnarts-ms
2012-02-06 21:08 ` Stefan Monnier
2012-02-06 21:53 ` Drew Adams
2012-02-07 3:02 ` Stefan Monnier
2012-02-07 12:04 ` egnarts-ms
2012-02-07 17:36 ` Stefan Monnier
2012-02-08 13:15 ` egnarts-ms
2012-02-08 19:07 ` Stefan Monnier
2012-02-07 12:29 ` egnarts-ms [this message]
2012-02-07 18:43 ` Nix
2012-02-07 19:11 ` Lennart Borgman
2012-02-07 19:15 ` Juanma Barranquero
2012-02-07 20:54 ` Lennart Borgman
2012-02-07 21:03 ` John Wiegley
2012-02-07 21:06 ` Nix
2012-02-07 21:08 ` Lennart Borgman
2012-02-07 21:10 ` Nix
2012-02-07 21:12 ` Lennart Borgman
2012-02-07 21:23 ` Nix
2012-02-07 21:29 ` Lennart Borgman
2012-02-07 21:30 ` Nix
2012-02-07 21:32 ` Glenn Morris
2012-02-07 21:34 ` Daniel Colascione
2012-02-07 21:42 ` Tom Tromey
2012-02-08 1:53 ` Leo
2012-02-07 22:16 ` Alan Mackenzie
2012-02-07 22:19 ` Nix
2012-02-08 13:28 ` Richard Stallman
2012-02-08 15:00 ` Tom Tromey
2012-02-09 6:29 ` Richard Stallman
2012-02-09 14:23 ` Eric Schulte
2012-02-10 15:44 ` Richard Stallman
2012-02-10 18:36 ` Tom Tromey
2012-02-10 15:52 ` Tom Tromey
2012-02-10 16:23 ` Drew Adams
2012-02-10 16:42 ` Ted Zlatanov
2012-02-09 6:30 ` Richard Stallman
2012-02-09 13:56 ` Ted Zlatanov
2012-02-10 15:44 ` Richard Stallman
2012-02-10 18:34 ` Tom Tromey
2012-02-10 15:48 ` Tom Tromey
2012-02-10 18:29 ` Stefan Monnier
2012-02-08 2:07 ` Stephen J. Turnbull
2012-02-07 22:41 ` Glenn Morris
2012-02-07 23:10 ` Nix
2012-02-08 13:42 ` Eric Schulte
2012-02-08 13:46 ` Lennart Borgman
2012-02-08 13:51 ` Eric Schulte
2012-02-08 15:29 ` Lennart Borgman
2012-02-08 15:39 ` Eric Schulte
2012-02-08 15:43 ` Lennart Borgman
2012-02-08 14:26 ` Drew Adams
2012-02-08 13:15 ` Teemu Likonen
2012-02-09 7:33 ` spam- or registry-related things in Gnus need cl at run-time? (was: CL package serious deficiencies) Reiner Steib
2012-02-09 16:39 ` spam- or registry-related things in Gnus need cl at run-time? Teemu Likonen
2012-02-07 23:48 ` CL package serious deficiencies Stefan Monnier
2012-02-07 23:52 ` Nix
2012-02-08 0:10 ` Lennart Borgman
2012-02-08 0:15 ` Nix
2012-02-08 1:51 ` Stefan Monnier
2012-02-08 23:43 ` Nix
2012-02-09 21:34 ` Stefan Monnier
2012-02-08 2:13 ` Stephen J. Turnbull
2012-02-08 2:19 ` Lennart Borgman
2012-02-08 4:23 ` Stephen J. Turnbull
2012-02-08 11:00 ` Lennart Borgman
2012-02-08 17:42 ` Richard Stallman
2012-02-08 19:54 ` Stefan Monnier
2012-02-08 0:38 ` Daniel Colascione
2012-02-08 1:32 ` Lennart Borgman
2012-02-08 1:53 ` Stefan Monnier
2012-02-08 2:26 ` Daniel Colascione
2012-02-08 22:28 ` Lars Ingebrigtsen
2012-02-08 22:32 ` Lennart Borgman
2012-02-08 23:35 ` Nix
2012-02-09 19:42 ` Richard Stallman
2012-02-09 19:46 ` Nix
2012-02-10 1:09 ` John Wiegley
2012-02-10 14:38 ` Stefan Monnier
2012-02-10 15:08 ` Juanma Barranquero
2012-02-10 15:35 ` Drew Adams
2012-02-10 18:15 ` Stefan Monnier
2012-02-10 18:21 ` Drew Adams
2012-02-10 15:24 ` Lars Ingebrigtsen
2012-02-10 18:24 ` Stefan Monnier
2012-02-10 18:26 ` Lars Ingebrigtsen
2012-02-10 18:47 ` Johan Bockgård
2012-02-10 17:12 ` Helmut Eller
2012-02-10 18:51 ` Stefan Monnier
2012-02-10 18:55 ` Lars Ingebrigtsen
2012-02-10 19:08 ` Teemu Likonen
2012-02-11 13:25 ` Juanma Barranquero
2012-02-11 16:56 ` Johan Bockgård
2012-02-11 22:33 ` Juanma Barranquero
2012-02-12 4:41 ` Stefan Monnier
2012-02-12 15:53 ` Teemu Likonen
2012-02-12 16:52 ` Stefan Monnier
2012-02-12 16:55 ` Stefan Monnier
2012-02-10 23:56 ` Helmut Eller
2012-02-12 4:47 ` Stefan Monnier
2012-02-12 17:39 ` Helmut Eller
2012-02-12 18:15 ` Stefan Monnier
2012-02-12 18:58 ` Helmut Eller
2012-02-19 12:52 ` Dimitri Fontaine
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=33278223.post@talk.nabble.com \
--to=egnartsms@gmail.com \
--cc=Emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).