From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: MON KEY Newsgroups: gmane.emacs.devel Subject: Re: Removing non `loop' features from cl.el - `cl-map-overlays', `cl-map-intervals', `cl-map-extents' Date: Sun, 12 Dec 2010 16:29:42 -0500 Message-ID: References: <87fwu3rzaq.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1292189401 20294 80.91.229.12 (12 Dec 2010 21:30:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 12 Dec 2010 21:30:01 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 12 22:29:57 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PRtUQ-00059r-Jp for ged-emacs-devel@m.gmane.org; Sun, 12 Dec 2010 22:29:57 +0100 Original-Received: from localhost ([127.0.0.1]:60851 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PRtUO-0001zr-UA for ged-emacs-devel@m.gmane.org; Sun, 12 Dec 2010 16:29:52 -0500 Original-Received: from [140.186.70.92] (port=33316 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PRtUJ-0001zj-Ef for emacs-devel@gnu.org; Sun, 12 Dec 2010 16:29:48 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PRtUH-00040j-Ti for emacs-devel@gnu.org; Sun, 12 Dec 2010 16:29:47 -0500 Original-Received: from mail-wy0-f169.google.com ([74.125.82.169]:37292) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PRtUH-00040f-Ie for emacs-devel@gnu.org; Sun, 12 Dec 2010 16:29:45 -0500 Original-Received: by wyj26 with SMTP id 26so5598957wyj.0 for ; Sun, 12 Dec 2010 13:29:44 -0800 (PST) Original-Received: by 10.216.156.84 with SMTP id l62mr3775543wek.58.1292189382815; Sun, 12 Dec 2010 13:29:42 -0800 (PST) Original-Received: by 10.216.70.212 with HTTP; Sun, 12 Dec 2010 13:29:42 -0800 (PST) In-Reply-To: <87fwu3rzaq.fsf@uwakimon.sk.tsukuba.ac.jp> X-Google-Sender-Auth: abcZ_v8oFzIJqw5NsmxT3RMfXg8 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:133631 Archived-At: On Sun, Dec 12, 2010 at 6:44 AM, Stephen J. Turnbull w= rote: > > Presumably this function is for compatibility with code written for > XEmacs. =C2=A0I don't see why anybody using GNU Emacs would need it. > Current w/ bzr revision 102585, anybody who uses `loop' w/ "being the overlays of" will run up against `cl-map-extents'. Whether `cl-map-extents' is a compatibility feature or not does not change that the GNU Emacs byte-compiler will still complain about it being called at runtime and it isn't clear that calling `cl-map-overlays' instead will muffle the byte-compiler whining. Which is why my example included loop forms which call to both `cl-map-intervals' and `cl-map-extents' when expanded. IOW, the issue is that the GNU Emacs byte-compiler warns about these functions being called at runtime even though as implemented they have _nothing_ to do with Common Lisp and the warnings have nothing to do with protecting the "global names". That `cl-map-extents' got caught up in the mix is (post 1999-12) a side-effect of the bigger issue. Namely, that if the policy around use of CL at runtime is to prevent "cl-" namespaced functions from being called at runtime but that (as currently implemented) the library itself requires use of banned CL features then either: - those features should be removed from CL; - those features should be moved into a non prejudiced namespace; Again, I am advocating that where the Common Lisp `loop' macro does not provide formal semantics for use of: intervals, overlay/extent, vconcating, buffers, windows, frames, key-bindings, etc. that these add-ons be removed from elisp implementation of `loop'. It is disingenuous to persist maintaining the CL runtime ban as a means of protecting the "global names" while also allowing `loop's feature creep. If the entire CL regime has the potential to encroach upon the global namespace then it would hold that any GNU Emacs extensions to the CL regime has in it this same potential. Likewise, where such extensions do exist there doesn't seem to be much will among the existing emacs-devel's to maintain the crept features. As evidenced here: ,---- | | From: Glenn Morris | Subject: Re: bug#7492: 23.2; cl loop over the windows: infinite loop, inf= o doc | Date: Mon, 29 Nov 2010 19:29:26 -0500 | | > It's not clear if/when the minibuffer window is included and in which | > order the iteration is done. | | By experiment, the minibuffer is not included, which is why it loops | forever if you force it to start there. Does the order matter? Anyway, | it's the order that `next-window' gives. | | `loop' can probably be improved, but I suggest using `walk-windows' | (which has well-defined, flexible behaviour wrt the minibuffer) | instead and will add a note to cl.texi to this effect. | `---- :SEE (URL `http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D7492') It is well and good that this bug is fixed and the manual updated (Thanks Glenn!), but this doesn't address the underlying problem which is that when users use the elisp `loop' macro expecting that where its semantics explicitly provide for an idiom that diverges from the Common Lisp semantics it should respond reasonably. My interpretation of RGM's response is that whether the order matters or not one would do better to use next-window/walk-windows. This is fine for what its worth but CL `loop'ing needn't be the same as or only involved of walking a tree of window objects, and in so much as `next-window' is a C primitive it isn't necessarily clear that `next-window'/`walk-windows' do have such particularly well defined behavior wrt the minibuffer at the _lisp_ level (flexible though this behavior may be). In any event the suggestion that next-window/walk-windows may be a better fit for such uses is more than a little amusing given that a good deal of the "window walking" in src/window.c is oriented around the heavy lifting of a function named... wait for it... "window_loop"! Of which most of its branches check MINI_WINDOW_P, e.g. around UNSHOW_BUFFER, GET_BUFFER_WINDOW, GET_LRU_WINDOW, etc. Whichever, the point is that it is wrong for the byte-compiler to penalize them when they use the elisp `loop' macro in a manner that GNU Emacs lisp provides for. esp. as doubtful few users are looking at the C in src/window.c when seeking a lispy solution for a window frobbing task any more than they are looking at lisp/windows.el or lisp/emacs-lisp/cl-macs.el So, while its perfectly reasonable for RGM et al to suggest that users might make better use of the elisp's interface to the underlying C window machinery it is unreasonable to expect that users be able to differentiate the relative merits of elisp's next-window/walk-windows as opposed to its implementation of the Common Lisp `loop' macro. >From the user perspective `walk-windows' and `loop' are each made of the same lispy goo. How is the user supposed to know that the `walk-windows' goo is comprised of a more privileged stuff than `loop's? Indeed, all else being equal, in terms of perceived utility to users the goo of the `loop' abstraction is most likely seen as more privileged than that of `walk-windows'/`next-window': rgrep in trunk/lisp matches ~335 uses of `loop' find . -type f -name "*.el" -print0 | xargs -0 -e grep -nH -e "(loop " rgrep in trunk/lisp matches ~20 uses of `walk-windows' find . -type f -name "*.el" -print0 | xargs -0 -e grep -nH -e "(walk-window= s " rgrep in trunk/lisp matches ~20 uses of `next-window' find . -type f -name "*.el" -print0 | xargs -0 -e grep -nH -e '(next-window= ' If what the byte-compiler really means to say when it barks: Warning: Function `' from cl package called at runtime is actually: Warning: Function `' from cl package is (as implemented) not as efficient nor as supported as an equivalent elisp function implemented by way of a platform specific GNU Emacs C primitive. Recommend to substitue with `'. Then that is what it should say. -- /s_P\