From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: egnarts-ms Newsgroups: gmane.emacs.devel Subject: RE: CL package serious deficiencies Date: Tue, 7 Feb 2012 04:29:15 -0800 (PST) Message-ID: <33278223.post@talk.nabble.com> References: <33271707.post@talk.nabble.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1328617767 27145 80.91.229.3 (7 Feb 2012 12:29:27 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 7 Feb 2012 12:29:27 +0000 (UTC) To: Emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 07 13:29:26 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RukAo-0001Ua-CX for ged-emacs-devel@m.gmane.org; Tue, 07 Feb 2012 13:29:26 +0100 Original-Received: from localhost ([::1]:34965 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RukAn-0006dl-PB for ged-emacs-devel@m.gmane.org; Tue, 07 Feb 2012 07:29:25 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:49301) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RukAk-0006df-Ut for Emacs-devel@gnu.org; Tue, 07 Feb 2012 07:29:24 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RukAe-0001QZ-H4 for Emacs-devel@gnu.org; Tue, 07 Feb 2012 07:29:22 -0500 Original-Received: from sam.nabble.com ([216.139.236.26]:52351) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RukAe-0001QU-BZ for Emacs-devel@gnu.org; Tue, 07 Feb 2012 07:29:16 -0500 Original-Received: from isper.nabble.com ([192.168.236.156]) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1RukAd-0006vw-FR for Emacs-devel@gnu.org; Tue, 07 Feb 2012 04:29:15 -0800 In-Reply-To: X-Nabble-From: egnartsms@gmail.com X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 216.139.236.26 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:148300 Archived-At: 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.