Re: Removing non `loop' features from cl.el - `cl-map-overlays', `cl-map-intervals', `cl-map-extents'

[MON KEY]

On Sun, Dec 12, 2010 at 6:44 AM, Stephen J. Turnbull <address@hidden> wrote:
>
> Presumably this function is for compatibility with code written for
> XEmacs.  I 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, info 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=7492')

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-windows "

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 `<cl-*>' from cl package called at runtime

is actually:

 Warning: Function `<cl-*>' 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 `<elisp-fun-name-here>'.

Then that is what it should say.

--
/s_P\