* moving more cl seq/mapping support into core @ 2010-09-24 22:48 MON KEY 2010-09-25 5:13 ` Leo 2010-09-27 19:07 ` MON KEY 0 siblings, 2 replies; 55+ messages in thread From: MON KEY @ 2010-09-24 22:48 UTC (permalink / raw) To: emacs-devel ,---- | :FROM: Chong Yidong | :SUBJECT: Re: Problems with xml-parse-string | :DATE: Fri, 24 Sep 2010 12:26:21 -0400 | | It is illogical to criticize sxml for wasting conses, while arguing for | wrapping each text node in a cons. | | Anyway, it is difficult to see how real the problem is without a | concrete example. Could you provide one? I suspect that the real | problem, if one exists, is Elisp's relatively weak support for list | mapping and reduction; if that's the case, the correct solution is to | pull in some of the relevant functions from the CL package. | | (URL `http://lists.gnu.org/archive/html/emacs-devel/2010-09/msg01250.html') `---- ,---- | | :FROM RMS | :SUBJECT Re: Emacs Package Management | :DATE Tue, 15 Sep 2009 03:16:50 -0400 | | | Could we then privide aliases like "cl-loop" for "loop" ? | | I am not against it. | | Maybe we could include Cl functions in the Emacs core | incrementaly then? Each CL function moved to the core would | require an agreement on the functions inclusion and a | documentation patch. | | That's more or less what we've been doing. Originally I strove very | hard to keep Emacs itself small. Many basic and obviously useful | functions were not standardly available, but they were in CL. Since | then we have made a number of them standard, and we could certainly | do this for more of them in the future when it seems best. | | But some of the CL facilities are overly complex. And some, | specifically setf and friends, are not implemented quite right in | the Emacs context, which makes them ugly to include. | | {...} | | :SEE (URL `http://lists.gnu.org/archive/html/emacs-devel/2009-09/msg00342.html') `---- Following is a list of symbols in other packages wich cl.el provides and which are duplicated either verbatim or indirectly to achieve the same affect and presumably to avoid cl.el runtime package requirements. These are without the `&keys` lambda-lists but some provide predicate type arguments to accomplish similiarly to :test `edmacro-subseq' <- `subseq' emacs-lisp/cl-extra.el `smtpmail-intersection' <- `intersection' emacs-lisp/cl-seq.el `dired-file-set-difference' <- `set-difference' lisp/dired-aux.el `edebug-gensym-index' <- `*gensym-counter*' emacs-lisp/cl-macs.el `edebug-gensym' <- `gensym' emacs-lisp/cl-macs.el `edebug-lambda-list-keywordp' could be improved by changing from: (and (symbolp object) (= ?& (aref (symbol-name object) 0))) to: (and (memq object lambda-list-keywords) t) e.g. (and (memq '&aux lambda-list-keywords) t) `lambda-list-keywords' is a constant in emacs-lisp/cl-macs.el erc/erc-compat.el `erc-member-if', `erc-delete-if', `erc-remove-if-not' `erc-subseq' is a verbatim duplicate of `subseq'. gnus-util.el has `gnus-merge' which is a modified version of cl.el's `merge' It does a noop for its TYPE arg (but includes it for compatibility) and omits the "&rest cl-keys" from its lambda-list. It also provides a function `gnus-mapcar' which is a variant of `mapcar*' without `cl-mapcar-many' dependence. `gnus-remove-if' is similar to `remove-if' without CL keywords. Are there any others like this that I've missed? Following is a list of cl.el derived feautres which don't appear (as best I can tell) to rely on cl keywords. I've attempted to enumerate where a given symbol carries a `cl-compiler-macro` property or `cl-byte-compile-compiler-macro` and `byte-compile-inline-expand` property values. Surely some of these are good canditdates for moving into core. They're certainly tested, documented and some of them are significantly optimized away by the byte-compiler. ;; artithmetic `gcd' ;(symbol-plist 'gcd) ;=> side-effect-free t `lcm' ;(symbol-plist 'lcm) ;=> side-effect-free t `isqrt' ;(symbol-plist 'isqrt) ;=> side-effect-free t `signum' ;(symbol-plist 'signum) ;=> side-effect-free t `equalp' ;(symbol-plist 'equalp) ;=> side-effect-free error-free `plusp' ;(symbol-plist 'plusp) ;=> side-effect-free t ; byte-compile cl-byte-compile-compiler-macro ; cl-compiler-macro (lambda (w x) (list (quote >) x 0)) `minusp' ;(symbol-plist 'minusp) ;=> side-effect-free t byte-compile ; cl-byte-compile-compiler-macro ; cl-compiler-macro (lambda (w x) (list (quote <) x 0))) `oddp' ;(symbol-plist 'oddp) ;=> side-effect-free t `evenp' ;(symbol-plist 'evenp) ;=> side-effect-free t ;; generalized `cl-set-frame-visible-p' ;; type `coerce' ;; matching `every' `some' `notevery' ;(symbol-plist 'notevery) ;=> byte-optimizer byte-compile-inline-expand `notany' ;(symbol-plist 'notany) ;=> byte-optimizer byte-compile-inline-expand ;; mapping `map' ;(symbol-plist 'map) ;=> byte-optimizer byte-compile-inline-expand `mapcon' `mapl' `cl-mapc' `maplist' `cl-mapcar-many' `cl-map-keymap-recursively' `cl-map-intervals' `cl-map-overlays' ;; seqs `concatenate' ;(symbol-plist 'concatenate) ;=> byte-optimizer byte-compile-inline-expand `revappend' ;(symbol-plist 'revappend) ;=> byte-optimizer byte-compile-inline-expand `nreconc' ;(symbol-plist 'nreconc) ;=> byte-optimizer byte-compile-inline-expand `list-length' ;(symbol-plist 'list-length) ;=> side-effect-free t `endp' ;(symbol-plist 'endp); ;=> side-effect-free t ; byte-compile cl-byte-compile-compiler-macro ; cl-compiler-macro (lambda (w x) (list (quote null) x))) `acons' ; (symbol-plist 'acons) ;=> side-effect-free error-free ; byte-optimizer byte-compile-inline-expand `list*' ;(symbol-plist 'list*) ;=> side-effect-free error-free ; byte-compile cl-byte-compile-compiler-macro ; compiler-macro-file "cl-macs.el" ; cl-compiler-macro #[ ...byte-code-vector elided ] `ldiff' ;(symbol-plist 'ldiff) ;=> side-effect-free t `pairlis' ;(symbol-plist 'pairlis) ;=> side-effect-free t ;; These don't have `cl-' namespacing for symbol-name or the local vars. `copy-list' `tailp' ;; This one doesn't have `cl-' namespacing for the local vars. `cl-maclisp-member' -- /s_P\ ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-09-24 22:48 moving more cl seq/mapping support into core MON KEY @ 2010-09-25 5:13 ` Leo 2010-09-25 5:58 ` Miles Bader 2010-09-26 10:37 ` Richard Stallman 2010-09-27 19:07 ` MON KEY 1 sibling, 2 replies; 55+ messages in thread From: Leo @ 2010-09-25 5:13 UTC (permalink / raw) To: emacs-devel On 2010-09-24 23:48 +0100, MON KEY wrote: > Following is a list of symbols in other packages wich cl.el provides > and which are duplicated either verbatim or indirectly to achieve the > same affect and presumably to avoid cl.el runtime package > requirements. Those functions are not there overnight they probably came from people's years of experience using and designing lisp. So they will be reinvented from time to time for writing any non-trivial elisp packages except now we have slightly different versions here and there. My wish is all of them should be incorporated into elisp. Leo ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-09-25 5:13 ` Leo @ 2010-09-25 5:58 ` Miles Bader 2010-09-25 14:42 ` Drew Adams 2010-09-26 10:37 ` Richard Stallman 1 sibling, 1 reply; 55+ messages in thread From: Miles Bader @ 2010-09-25 5:58 UTC (permalink / raw) To: emacs-devel Leo <sdl.web@gmail.com> writes: > Those functions are not there overnight they probably came from people's > years of experience using and designing lisp. So they will be reinvented > from time to time for writing any non-trivial elisp packages except now > we have slightly different versions here and there. > > My wish is all of them should be incorporated into elisp. Some CL functions are so trivial that it's not hard to move them (e.g., gensym, though I've somehow gotten the impression it's frowned on these days), but more tricky are those of obvious usefulness, that have keyword-heavy interfaces in CL (though I think it's quite common that in many cases few or none of the keyword argument are actually used very often). For instance, `remove-if' is obviously useful (I think it's often one of those "I use cl.el for that function" functions), not complex, and could probably be moved into the core in some simplified form. Suggested function signature: (remove-if PREDICATE SEQ [TEST]) -- and of course, change the cl.el version to deal with TEST as well. -Miles p.s. Another [kinda related to remove-if] that I've often wanted to use, but didn't because it wasn't in the core, is `mapcan' -- and nit doesn't even have any keywords! -- Justice, n. A commodity which in a more or less adulterated condition the State sells to the citizen as a reward for his allegiance, taxes and personal service. ^ permalink raw reply [flat|nested] 55+ messages in thread
* RE: moving more cl seq/mapping support into core 2010-09-25 5:58 ` Miles Bader @ 2010-09-25 14:42 ` Drew Adams 2010-09-25 15:07 ` Leo 2010-09-25 21:26 ` Miles Bader 0 siblings, 2 replies; 55+ messages in thread From: Drew Adams @ 2010-09-25 14:42 UTC (permalink / raw) To: 'Miles Bader', emacs-devel > For instance, `remove-if' is obviously useful (I think it's > often one of those "I use cl.el for that function" functions), not > complex, and could probably be moved into the core in some > simplified form. > > Suggested function signature: (remove-if PREDICATE SEQ [TEST]) -- and > of course, change the cl.el version to deal with TEST as well. +1 for remove-if(-not) But I don't know what you meant by TEST. AFAIK, the CL signature is this: remove-if PREDICATE SEQ &key :from-end :start :end :count :key Maybe you were thinking of `remove', which has `:test'? ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-09-25 14:42 ` Drew Adams @ 2010-09-25 15:07 ` Leo 2010-09-25 15:23 ` Drew Adams 2010-09-25 21:26 ` Miles Bader 1 sibling, 1 reply; 55+ messages in thread From: Leo @ 2010-09-25 15:07 UTC (permalink / raw) To: emacs-devel On 2010-09-25 15:42 +0100, Drew Adams wrote: > +1 for remove-if(-not) > > But I don't know what you meant by TEST. > AFAIK, the CL signature is this: > > remove-if PREDICATE SEQ &key :from-end :start :end :count :key I think Miles was talking about making a new remove-if that accepts an optional argument, one that is not second class. Leo ^ permalink raw reply [flat|nested] 55+ messages in thread
* RE: moving more cl seq/mapping support into core 2010-09-25 15:07 ` Leo @ 2010-09-25 15:23 ` Drew Adams 2010-09-25 15:30 ` Leo 0 siblings, 1 reply; 55+ messages in thread From: Drew Adams @ 2010-09-25 15:23 UTC (permalink / raw) To: 'Leo', emacs-devel > > But I don't know what you meant by TEST. > > AFAIK, the CL signature is this: > > > > remove-if PREDICATE SEQ &key :from-end :start :end :count :key > > I think Miles was talking about making a new remove-if that accepts an > optional argument, one that is not second class. Sorry, I don't get it. What is TEST for? It is typically for a binary predicate such as `equal' - but we already have PREDICATE here. And just what is second class here (if TEST is not added)? ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-09-25 15:23 ` Drew Adams @ 2010-09-25 15:30 ` Leo 2010-09-25 15:33 ` David Kastrup ` (2 more replies) 0 siblings, 3 replies; 55+ messages in thread From: Leo @ 2010-09-25 15:30 UTC (permalink / raw) To: emacs-devel On 2010-09-25 16:23 +0100, Drew Adams wrote: > Sorry, I don't get it. What is TEST for? It is typically for a binary > predicate such as `equal' - but we already have PREDICATE here. And just what > is second class here (if TEST is not added)? `remove-if' as defined in cl.el can not be used in a package intended to be included in GNU Emacs due to the use of cl run time functions. So to move this function into elisp Miles (I think) proposed that we give up some of its keyword arguments since they mostly are not used and turned the keyword :test argument into an optional one. Leo ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-09-25 15:30 ` Leo @ 2010-09-25 15:33 ` David Kastrup 2010-09-25 15:55 ` Drew Adams 2010-09-25 15:55 ` Drew Adams 2010-10-01 0:33 ` Daniel Colascione 2 siblings, 1 reply; 55+ messages in thread From: David Kastrup @ 2010-09-25 15:33 UTC (permalink / raw) To: emacs-devel Leo <sdl.web@gmail.com> writes: > On 2010-09-25 16:23 +0100, Drew Adams wrote: >> Sorry, I don't get it. What is TEST for? It is typically for a binary >> predicate such as `equal' - but we already have PREDICATE here. And just what >> is second class here (if TEST is not added)? > > `remove-if' as defined in cl.el can not be used in a package intended to > be included in GNU Emacs due to the use of cl run time functions. > > So to move this function into elisp Miles (I think) proposed that we > give up some of its keyword arguments since they mostly are not used and > turned the keyword :test argument into an optional one. I found that quite a few use cases can be dealt with by using the idiom (delq nil ...) instead. -- David Kastrup ^ permalink raw reply [flat|nested] 55+ messages in thread
* RE: moving more cl seq/mapping support into core 2010-09-25 15:33 ` David Kastrup @ 2010-09-25 15:55 ` Drew Adams 0 siblings, 0 replies; 55+ messages in thread From: Drew Adams @ 2010-09-25 15:55 UTC (permalink / raw) To: 'David Kastrup', emacs-devel > I found that quite a few use cases can be dealt with by using > the idiom (delq nil ...) instead. Agreed. And there are lots of other ways to do it. But `remove-if(-not)' is still handy, IMO. ^ permalink raw reply [flat|nested] 55+ messages in thread
* RE: moving more cl seq/mapping support into core 2010-09-25 15:30 ` Leo 2010-09-25 15:33 ` David Kastrup @ 2010-09-25 15:55 ` Drew Adams 2010-09-25 16:01 ` Leo 2010-10-01 0:33 ` Daniel Colascione 2 siblings, 1 reply; 55+ messages in thread From: Drew Adams @ 2010-09-25 15:55 UTC (permalink / raw) To: 'Leo', emacs-devel > > Sorry, I don't get it. What is TEST for? It is typically > > for a binary predicate such as `equal' - but we already have > > PREDICATE here. And just what is second class here (if TEST > > is not added)? > > `remove-if' as defined in cl.el can not be used in a package > intended to be included in GNU Emacs due to the use of cl run > time functions. > > So to move this function into elisp Miles (I think) proposed that we > give up some of its keyword arguments since they mostly are > not used and turned the keyword :test argument into an optional one. We are not communicating, I think. At least I am not understanding you. Turned what :test argument into an optional one? There is _no_ :test argument to `remove-if' (in CL). Do you perhaps mean :key? Sorry, I don't follow you at all. Again, AFAIK, this is the CL sig: remove-if PREDICATE SEQ &key :from-end :start :end :count :key ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-09-25 15:55 ` Drew Adams @ 2010-09-25 16:01 ` Leo 0 siblings, 0 replies; 55+ messages in thread From: Leo @ 2010-09-25 16:01 UTC (permalink / raw) To: emacs-devel On 2010-09-25 16:55 +0100, Drew Adams wrote: > remove-if PREDICATE SEQ &key :from-end :start :end :count :key Oh, looks like I mixed up. You are right. Leo ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-09-25 15:30 ` Leo 2010-09-25 15:33 ` David Kastrup 2010-09-25 15:55 ` Drew Adams @ 2010-10-01 0:33 ` Daniel Colascione 2 siblings, 0 replies; 55+ messages in thread From: Daniel Colascione @ 2010-10-01 0:33 UTC (permalink / raw) To: Leo; +Cc: emacs-devel On 9/25/2010 8:30 AM, Leo wrote: > On 2010-09-25 16:23 +0100, Drew Adams wrote: >> Sorry, I don't get it. What is TEST for? It is typically for a binary >> predicate such as `equal' - but we already have PREDICATE here. And just what >> is second class here (if TEST is not added)? > > `remove-if' as defined in cl.el can not be used in a package intended to > be included in GNU Emacs due to the use of cl run time functions. > > So to move this function into elisp Miles (I think) proposed that we > give up some of its keyword arguments since they mostly are not used and > turned the keyword :test argument into an optional one. Why bother? A compiler-macro can examine a call to remove-if, see whether it recognizes the keyword arguments, and if it does, transform the whole call into something more lightweight. You retain the current function's expressive power and CL compatibility while losing nothing in performance. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-09-25 14:42 ` Drew Adams 2010-09-25 15:07 ` Leo @ 2010-09-25 21:26 ` Miles Bader 1 sibling, 0 replies; 55+ messages in thread From: Miles Bader @ 2010-09-25 21:26 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel On Sat, Sep 25, 2010 at 11:42 PM, Drew Adams <drew.adams@oracle.com> wrote: >> For instance, `remove-if' is obviously useful (I think it's >> often one of those "I use cl.el for that function" functions), not >> complex, and could probably be moved into the core in some >> simplified form. >> >> Suggested function signature: (remove-if PREDICATE SEQ [TEST]) -- and >> of course, change the cl.el version to deal with TEST as well. > > +1 for remove-if(-not) > > But I don't know what you meant by TEST. > AFAIK, the CL signature is this: > > remove-if PREDICATE SEQ &key :from-end :start :end :count :key > > Maybe you were thinking of `remove', which has `:test'? Ah, yes, indeed. That makes adding remove-if even simpler of course! -miles -- Cat is power. Cat is peace. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-09-25 5:13 ` Leo 2010-09-25 5:58 ` Miles Bader @ 2010-09-26 10:37 ` Richard Stallman 2010-09-26 13:13 ` Leo 1 sibling, 1 reply; 55+ messages in thread From: Richard Stallman @ 2010-09-26 10:37 UTC (permalink / raw) To: Leo; +Cc: emacs-devel Those functions are not there overnight they probably came from people's years of experience using and designing lisp. So they will be reinvented from time to time for writing any non-trivial elisp packages except now we have slightly different versions here and there. My wish is all of them should be incorporated into elisp. Since they would occupy parts of the address space that users expect is theirs, we would need to document them all in the Lisp manual. Aside from that, the keyword-based interfaces of these functions does not fit the style of Emacs Lisp very well. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-09-26 10:37 ` Richard Stallman @ 2010-09-26 13:13 ` Leo 2010-09-26 19:32 ` Miles Bader 2010-09-27 6:27 ` Richard Stallman 0 siblings, 2 replies; 55+ messages in thread From: Leo @ 2010-09-26 13:13 UTC (permalink / raw) To: emacs-devel On 2010-09-26 11:37 +0100, Richard Stallman wrote: > Since they would occupy parts of the address space that users expect > is theirs, we would need to document them all in the Lisp manual. Thanks. I think we need not to worry the user address space too much. Those functions are descriptive so it is unlikely someone wants to name a function say remove-if that does something different. Even if they do they can still play with the name by adding *, +, ++, x etc as we have seen in many places. The majority can continue to like what remove-if does. > Aside from that, the keyword-based interfaces of these functions does > not fit the style of Emacs Lisp very well. But all the major build blocks like define-derived-mode, defcustom, define-minor-mode, easy-menu-define etc use keyword arguments. And completing-read, I often want to specify the DEF argument and it is pretty difficult to remember where it is without checking it out with C-h f. Leo ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-09-26 13:13 ` Leo @ 2010-09-26 19:32 ` Miles Bader 2010-09-27 6:27 ` Richard Stallman 1 sibling, 0 replies; 55+ messages in thread From: Miles Bader @ 2010-09-26 19:32 UTC (permalink / raw) To: emacs-devel Leo <sdl.web@gmail.com> writes: >> Aside from that, the keyword-based interfaces of these functions does >> not fit the style of Emacs Lisp very well. > > But all the major build blocks like define-derived-mode, defcustom, > define-minor-mode, easy-menu-define etc use keyword arguments. Emacs sometimes uses keywords for complex top-level nobody-expects-them-to-be-fast functions/macros. CL uses keywords for just about every function in the language. There's a distinct difference in style, and that should be respected. -Miles -- Circus, n. A place where horses, ponies and elephants are permitted to see men, women and children acting the fool. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-09-26 13:13 ` Leo 2010-09-26 19:32 ` Miles Bader @ 2010-09-27 6:27 ` Richard Stallman 2010-10-01 0:28 ` Daniel Colascione 1 sibling, 1 reply; 55+ messages in thread From: Richard Stallman @ 2010-09-27 6:27 UTC (permalink / raw) To: Leo; +Cc: emacs-devel Thanks. I think we need not to worry the user address space too much. That would be a change for the worse in our standard of documentation. > Aside from that, the keyword-based interfaces of these functions does > not fit the style of Emacs Lisp very well. But all the major build blocks like define-derived-mode, defcustom, define-minor-mode, easy-menu-define etc use keyword arguments. Those are all rather heavy things by nature, so if the calling sequence is heavy too, that's ok. If I added a `remove-if' function I would like it not to be so heavy to use. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-09-27 6:27 ` Richard Stallman @ 2010-10-01 0:28 ` Daniel Colascione 2010-10-01 3:16 ` Miles Bader ` (2 more replies) 0 siblings, 3 replies; 55+ messages in thread From: Daniel Colascione @ 2010-10-01 0:28 UTC (permalink / raw) To: rms, emacs-devel On 9/26/2010 11:27 PM, Richard Stallman wrote: > Thanks. I think we need not to worry the user address space too much. > > That would be a change for the worse > in our standard of documentation. Every Emacs release adds all sorts of functions that might impinge on the user namespace, but it's rarely a problem in practice. CL shouldn't be held to a higher standard. In practice, many people (require 'cl) almost immediately, and a large number of packages, even those in GNU Emacs, (eval-when-compile '(require 'cl)). If cl namespace were actually a problem, we'd have heard about it long before now. In short, I really don't buy the argument that CL would cause too much namespace pollution. The benefits outweigh the tiny risk to the small number of users who work without CL loaded. CL really should be dumped along with Emacs proper. > Those are all rather heavy things by nature, so if the calling > sequence is heavy too, that's ok. > If I added a `remove-if' function I would like it not to be so heavy > to use. You can use compiler-macros (or an equivalent) to create "fast" calls when the keywords involved are known beforehand, as they almost always are. But the current CL functions are fast enough *now*, considering that they're widely used. If profiling reports that a particular call is too slow, it can always be replaced with lower-level functionality. But for the majority of code that isn't on the fast path, having CL primitives available will greatly simplify implementation. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-01 0:28 ` Daniel Colascione @ 2010-10-01 3:16 ` Miles Bader 2010-10-01 20:39 ` Daniel Colascione 2010-10-01 11:42 ` Richard Stallman 2010-10-01 11:42 ` Richard Stallman 2 siblings, 1 reply; 55+ messages in thread From: Miles Bader @ 2010-10-01 3:16 UTC (permalink / raw) To: emacs-devel Daniel Colascione <dan.colascione@gmail.com> writes: > CL really should be dumped along with Emacs proper. cl.el is a combination of good useful things that and horrible ugly things (this isn't a comment on the CL language, btw -- many of the problems with cl.el are issue with its implementation and consistency with elisp). That's one of the big problems with it: it's a big undifferentiated blob (to be fair, it was written a long time ago, back when the state of elisp programming practice was ... less nice). I interpret the consistent refusal to sanction cl.el to be a simple resistance to wholesale adoption of ugly things, even if that means some loss in terms of good things (perhaps with some intent to pressure people into fixing the problems). Users don't typically care of course -- they can simply ignore what they don't like and use the 5 function in cl.el they really find useful. But the elisp maintainers need to care. Of course, there's a solution which would probably make everybody happy: adopt the good things only, and fix some of the problems with the horrible ugly things so that they can be adopted. But people advocating cl.el seem to usually stop short of putting any effort into doing that... -Miles -- "Suppose we've chosen the wrong god. Every time we go to church we're just making him madder and madder." -- Homer Simpson ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-01 3:16 ` Miles Bader @ 2010-10-01 20:39 ` Daniel Colascione 2010-10-02 7:12 ` David Kastrup 0 siblings, 1 reply; 55+ messages in thread From: Daniel Colascione @ 2010-10-01 20:39 UTC (permalink / raw) To: emacs-devel, miles On 9/30/2010 8:16 PM, Miles Bader wrote: > Daniel Colascione <dan.colascione@gmail.com> writes: >> CL really should be dumped along with Emacs proper. > > cl.el is a combination of good useful things that and horrible ugly > things (this isn't a comment on the CL language, btw -- many of the > problems with cl.el are issue with its implementation and consistency > with elisp). Can you point to a few examples? Parts of cl are ugly (the common use of make-symbol instead of gensym, for example, makes macroexpansions difficult to read). But those don't affect functionality or interaction with other packages. The other issue is the set of extension functions --- defun*, defmacro* and so on. If your point is that the functionality offered by these functions should instead of folded into the regular elisp versions, then that's a good thing, but news to me. > Of course, there's a solution which would probably make everybody > happy: adopt the good things only, and fix some of the problems with > the horrible ugly things so that they can be adopted. But people > advocating cl.el seem to usually stop short of putting any effort into > doing that... What are the good things/ What are the "horrible ugly thing"? What criteria can you use to distinguish them? ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-01 20:39 ` Daniel Colascione @ 2010-10-02 7:12 ` David Kastrup 2010-10-03 23:15 ` Stefan Monnier 0 siblings, 1 reply; 55+ messages in thread From: David Kastrup @ 2010-10-02 7:12 UTC (permalink / raw) To: emacs-devel Daniel Colascione <dan.colascione@gmail.com> writes: > On 9/30/2010 8:16 PM, Miles Bader wrote: >> Daniel Colascione <dan.colascione@gmail.com> writes: >>> CL really should be dumped along with Emacs proper. >> >> cl.el is a combination of good useful things that and horrible ugly >> things (this isn't a comment on the CL language, btw -- many of the >> problems with cl.el are issue with its implementation and consistency >> with elisp). > > Can you point to a few examples? Parts of cl are ugly (the common use of > make-symbol instead of gensym, for example, makes macroexpansions > difficult to read). But those don't affect functionality or interaction > with other packages. That should be possible to solve with lex-bind. -- David Kastrup ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-02 7:12 ` David Kastrup @ 2010-10-03 23:15 ` Stefan Monnier 2010-10-04 17:41 ` Daniel Colascione 0 siblings, 1 reply; 55+ messages in thread From: Stefan Monnier @ 2010-10-03 23:15 UTC (permalink / raw) To: emacs-devel >> Can you point to a few examples? Parts of cl are ugly (the common use of >> make-symbol instead of gensym, for example, makes macroexpansions >> difficult to read). The use of make-symbol is a fairly recent change, to avoid filling the obarray with an ever-increasing number of temporary symbols. Stefan ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-03 23:15 ` Stefan Monnier @ 2010-10-04 17:41 ` Daniel Colascione 2010-10-05 23:32 ` Stefan Monnier 0 siblings, 1 reply; 55+ messages in thread From: Daniel Colascione @ 2010-10-04 17:41 UTC (permalink / raw) To: Stefan Monnier, emacs-devel On 10/3/2010 4:15 PM, Stefan Monnier wrote: >>> Can you point to a few examples? Parts of cl are ugly (the common use of >>> make-symbol instead of gensym, for example, makes macroexpansions >>> difficult to read). > > The use of make-symbol is a fairly recent change, to avoid filling the > obarray with an ever-increasing number of temporary symbols. But gensymed symbols aren't interned and should be GCed when no longer referenced. I thought make-symbol was used just to avoid having to cons up a new string for the symbol name. Regardless, it'd be nice to be able to switch that off to make some macro-expansions legible (or maybe I should write a tree walker that disambiguates identically-named but distinct symbols). ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-04 17:41 ` Daniel Colascione @ 2010-10-05 23:32 ` Stefan Monnier 0 siblings, 0 replies; 55+ messages in thread From: Stefan Monnier @ 2010-10-05 23:32 UTC (permalink / raw) To: Daniel Colascione; +Cc: emacs-devel >>>> Can you point to a few examples? Parts of cl are ugly (the common use of >>>> make-symbol instead of gensym, for example, makes macroexpansions >>>> difficult to read). >> The use of make-symbol is a fairly recent change, to avoid filling the >> obarray with an ever-increasing number of temporary symbols. > But gensymed symbols aren't interned and should be GCed when no longer > referenced. I thought make-symbol was used just to avoid having to cons > up a new string for the symbol name. Oh, you're right. Yes, it's because it's silly to waste time and space changing the symbol's names. > Regardless, it'd be nice to be able to switch that off to make some > macro-expansions legible (or maybe I should write a tree walker that > disambiguates identically-named but distinct symbols). The problem is the printed representation, not the use of make-symbol. The printed representation should use #= and friends to make it clear which symbols are uninterned and which ones are identical or not. Stefan ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-01 0:28 ` Daniel Colascione 2010-10-01 3:16 ` Miles Bader @ 2010-10-01 11:42 ` Richard Stallman 2010-10-01 20:36 ` Daniel Colascione 2010-10-01 11:42 ` Richard Stallman 2 siblings, 1 reply; 55+ messages in thread From: Richard Stallman @ 2010-10-01 11:42 UTC (permalink / raw) To: Daniel Colascione; +Cc: emacs-devel Every Emacs release adds all sorts of functions that might impinge on the user namespace, Would you please give some examples for a recent release, so it will be clear whether you are talking about the same issue? Most functions in Emacs have name prefixes or suffixes which help prevent name conflicts; those names don't pose a problem. We only rarely add names like `remove-if' which have nothing in the name to keep them out of the user's way, and we normally document such names in the manual. If that practice has changed, I would like to know. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-01 11:42 ` Richard Stallman @ 2010-10-01 20:36 ` Daniel Colascione 0 siblings, 0 replies; 55+ messages in thread From: Daniel Colascione @ 2010-10-01 20:36 UTC (permalink / raw) To: rms; +Cc: emacs-devel On 10/1/2010 4:42 AM, Richard Stallman wrote: > Every Emacs release adds all sorts of functions that might impinge on > the user namespace, > > Would you please give some examples for a recent release, so it will > be clear whether you are talking about the same issue? > > Most functions in Emacs have name prefixes or suffixes which help > prevent name conflicts; those names don't pose a problem. We only > rarely add names like `remove-if' which have nothing in the name to > keep them out of the user's way, and we normally document such names > in the manual. If that practice has changed, I would like to know. Even prefixed functions and symbols can conflict with something the user has specified; the likelihood is just lower. In general, CL symbols, even without a namespace qualification, won't cause problems because cl is *already* so widely-used that anything that would conflict with it has already been fixed. Can you provide a real example of something that would break if cl.el were dumped with Emacs? ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-01 0:28 ` Daniel Colascione 2010-10-01 3:16 ` Miles Bader 2010-10-01 11:42 ` Richard Stallman @ 2010-10-01 11:42 ` Richard Stallman 2010-10-01 20:34 ` Daniel Colascione 2 siblings, 1 reply; 55+ messages in thread From: Richard Stallman @ 2010-10-01 11:42 UTC (permalink / raw) To: Daniel Colascione; +Cc: emacs-devel > Those are all rather heavy things by nature, so if the calling > sequence is heavy too, that's ok. > If I added a `remove-if' function I would like it not to be so heavy > to use. You can use compiler-macros (or an equivalent) to create "fast" calls when the keywords involved are known beforehand, as they almost always are. Indeed, one could do that. However, that doesn't mean that it is unimportant to choose a good, convenient interface as the one we offer and document. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-01 11:42 ` Richard Stallman @ 2010-10-01 20:34 ` Daniel Colascione 2010-10-01 21:12 ` Chong Yidong 0 siblings, 1 reply; 55+ messages in thread From: Daniel Colascione @ 2010-10-01 20:34 UTC (permalink / raw) To: rms; +Cc: emacs-devel On 10/1/2010 4:42 AM, Richard Stallman wrote: > > Those are all rather heavy things by nature, so if the calling > > sequence is heavy too, that's ok. > > If I added a `remove-if' function I would like it not to be so heavy > > to use. > > You can use compiler-macros (or an equivalent) to create "fast" calls > when the keywords involved are known beforehand, as they almost always > are. > > Indeed, one could do that. However, that doesn't mean that it is > unimportant to choose a good, convenient interface as the one we offer > and document. I understood the primary objection to keyword arguments being about efficiency. Compiler macros solve that problem. If you instead want to discuss the convenience of keyword arguments --- well, they're hard to beat. Functions that take a large number of arguments with various ad-hoc parameter meanings (I'm looking at you, write-region) are a nightmare to use, and keyword argument would greatly simplify their use (which is probably why play-sound takes keyword arguments). ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-01 20:34 ` Daniel Colascione @ 2010-10-01 21:12 ` Chong Yidong 0 siblings, 0 replies; 55+ messages in thread From: Chong Yidong @ 2010-10-01 21:12 UTC (permalink / raw) To: Daniel Colascione; +Cc: rms, emacs-devel Daniel Colascione <dan.colascione@gmail.com> writes: > I understood the primary objection to keyword arguments being about > efficiency. No; as RMS and Miles have pointed out, it's also a matter of style. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-09-24 22:48 moving more cl seq/mapping support into core MON KEY 2010-09-25 5:13 ` Leo @ 2010-09-27 19:07 ` MON KEY 2010-10-02 5:35 ` MON KEY 1 sibling, 1 reply; 55+ messages in thread From: MON KEY @ 2010-09-27 19:07 UTC (permalink / raw) To: emacs-devel On Fri, Sep 24, 2010 at 6:48 PM, MON KEY <monkey@sandpframing.com> wrote: > > Are there any others like this that I've missed? > Looks like I missed `edmacro-mismatch' . This is mismatch from cl-seq.el with "mandatory keywords"... The signatures of the two functions are quite similiar: (edmacro-mismatch seq1 seq2 start1 end1 start2 end2) (mismatch seq1 seq2 [keyword value]...) Note, that the _real_ source level signature of `edmacro-mismatch' is: (edmacro-mismatch cl-seq1 cl-seq2 cl-start1 cl-end1 cl-start2 cl-end2) Indeed `edmacro-mismatch's local vars even "borrow" from the cl "namespace" in that it let binds cl-from-end, cl-test, cl-test-not, cl-key, and cl-from-end. Curiously (for me anyhow) `edmacro-mismatch's has to let bind over cl-test and cl-test-not locals b/c like its cl.el counterpart `edmacro-mismatch' even evaluates `cl-check-match', i.e. it has to go out of its way to nullify the test symbols. As such the difference between the two functions is that `edmacro-mismatch' doesn't evaluate the `cl-parsing-keywords' macro and offers the same basic set of keywords (lest :test :test-not) they just aren't opaquely lumped into an &rest as with `mismatch'. Following is the wordwise diff of the two functions: *************** *** 1,11 **** ! (defun mismatch (cl-seq1 cl-seq2 &rest cl-keys) "Compare SEQ1 with SEQ2, return index of first mismatching element. Return nil if the sequences match. If one sequence is a prefix of the ! other, the return value indicates the end of the shorter sequence. ! \nKeywords supported: :test :test-not :key :start1 :end1 :start2 :end2 :from-end ! \n(fn SEQ1 SEQ2 [KEYWORD VALUE]...)" ! (cl-parsing-keywords (:test :test-not :key :from-end ! (:start1 0) :end1 (:start2 0) :end2) () (or cl-end1 (setq cl-end1 (length cl-seq1))) (or cl-end2 (setq cl-end2 (length cl-seq2))) (if cl-from-end --- 1,9 ---- ! (defun edmacro-mismatch (cl-seq1 cl-seq2 cl-start1 cl-end1 cl-start2 cl-end2) "Compare SEQ1 with SEQ2, return index of first mismatching element. Return nil if the sequences match. If one sequence is a prefix of the ! other, the return value indicates the end of the shorted sequence. ! \n(fn SEQ1 SEQ2 START1 END1 START2 END2)" ! (let (cl-test cl-test-not cl-key cl-from-end) (or cl-end1 (setq cl-end1 (length cl-seq1))) (or cl-end2 (setq cl-end2 (length cl-seq2))) (if cl-from-end -- /s_P\ ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-09-27 19:07 ` MON KEY @ 2010-10-02 5:35 ` MON KEY 2010-10-04 2:03 ` Richard Stallman 0 siblings, 1 reply; 55+ messages in thread From: MON KEY @ 2010-10-02 5:35 UTC (permalink / raw) To: emacs-devel Daniel Colascione wrote: > What are the good things/ What are the "horrible ugly thing"? What > criteria can you use to distinguish them? Maybe the better question is, in anticipation of lexical scoping which of these distinguishing criteria will no longer be relevant? Whatever the current/existing rationales may be, surely _some_ will cease to be relevant by any reasonably sane justification in lieu of lexically scoped environments. I would very much like to know now _concretely_ what the existing criteria are so that these may be revisited as the lexbind integration moves forward. cl.el is now at least 13 yrs old and the arguments precluding its integration remain largely the same as they were when Dave Gillespie advocated cl.el inclusion in core way back when. In the interim a good deal has changed with Emacs but the cl.el runtime ban still lingers... though the justifications have been allowed to shift. It is important that those willing to revisit/revise the cl.el deficiencies have a clear roadmap/guideline as to what is acceptable, why, and what the sane justifications for these guidelines are. As it is, I've made a preliminary effort to indicate those cl.el like features which are duplicated in other diverse emacs core libraries. It is clear that these features are needed/desired or they wouldn't exist. What is not clear is why if these features are desirable must they be reproduced w/ only minor modification simply to avoid the appearance of haring the cl namespace. In particular I would point to `edmacro-mismatch' as an example of such needless bending over backwards. -- /s_P\ ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-02 5:35 ` MON KEY @ 2010-10-04 2:03 ` Richard Stallman 2010-10-04 5:51 ` MON KEY 2010-10-04 17:33 ` Daniel Colascione 0 siblings, 2 replies; 55+ messages in thread From: Richard Stallman @ 2010-10-04 2:03 UTC (permalink / raw) To: MON KEY; +Cc: emacs-devel Whatever the current/existing rationales may be, surely _some_ will cease to be relevant by any reasonably sane justification in lieu of lexically scoped environments. I don't think that relates to this issue. This issue is about global names. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-04 2:03 ` Richard Stallman @ 2010-10-04 5:51 ` MON KEY 2010-10-06 5:21 ` Richard Stallman 2010-10-04 17:33 ` Daniel Colascione 1 sibling, 1 reply; 55+ messages in thread From: MON KEY @ 2010-10-04 5:51 UTC (permalink / raw) To: rms; +Cc: emacs-devel On Sun, Oct 3, 2010 at 10:03 PM, Richard Stallman <rms@gnu.org> wrote: > > I don't think that relates to this issue. It can't not relate. > > This issue is about global names. > Here's the thing about the global names "issue" that I find particularly irksome: (let ((tf "./some-temp-file")) (with-temp-file tf (insert "(defun reduce (arg1)\n arg1)" "\n(reduce 'bubba)")) (byte-compile-file tf) (when (get-buffer "*Compile-Log*") (display-buffer "*Compile-Log*")) (delete-file tf)) Does your *Compile-Log* buffer have this warning: ,---- | | In reduce: | some-temp-file:1:8:Warning: function reduce used to take 2+ arguments, now | takes 1 | some-temp-file:3:10:Warning: Function `reduce' from cl package called at | runtime | `---- If so, how does one justify this second warning as a protection of the global names? Either `reduce' is a privileged global name, or it is available to me (the user) to bind without qualification. So which is it, do I get to bind `reduce' at my leisure and without spurious CL related byte-compiler warnings, or is the runtime ban a self-perpetuating and (oft broken) policy? Note, the third way isn't much better: "Our regime of "protecting" the global names and the user from herself can appear at once authoritarian and sloppy. We apologize for any inconvenience this might cause but it is for the best of all parties concerned that it be this way." -- /s_P\ ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-04 5:51 ` MON KEY @ 2010-10-06 5:21 ` Richard Stallman 2010-10-09 0:29 ` MON KEY 0 siblings, 1 reply; 55+ messages in thread From: Richard Stallman @ 2010-10-06 5:21 UTC (permalink / raw) To: MON KEY; +Cc: emacs-devel Here's the thing about the global names "issue" that I find particularly irksome: (let ((tf "./some-temp-file")) (with-temp-file tf (insert "(defun reduce (arg1)\n arg1)" "\n(reduce 'bubba)")) (byte-compile-file tf) (when (get-buffer "*Compile-Log*") (display-buffer "*Compile-Log*")) (delete-file tf)) This writes a file that defines `reduce' globally. | some-temp-file:1:8:Warning: function reduce used to take 2+ arguments, now | takes 1 | some-temp-file:3:10:Warning: Function `reduce' from cl package called at | runtime I guess you had already loaded cl. The purpose of this warning is to encourage people not to write their code to call cl at run time. I think it was intended to operate in files that load cl at compile time and don't require cl at run time. The occurrence of the message in this case seems like a bug. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-06 5:21 ` Richard Stallman @ 2010-10-09 0:29 ` MON KEY 2010-10-10 5:09 ` Richard Stallman 0 siblings, 1 reply; 55+ messages in thread From: MON KEY @ 2010-10-09 0:29 UTC (permalink / raw) To: rms; +Cc: emacs-devel On Wed, Oct 6, 2010 at 1:21 AM, Richard Stallman <rms@gnu.org> wrote: > > I guess you had already loaded cl. > Yes, apparently so. Indeed, the warning does not appear with an "emacs -Q" > The purpose of this warning is to encourage people not to write their code > to call cl at run time. > > I think it was intended to operate in files that load cl at compile > time and don't require cl at run time. OK. But, the CL wasn't called at runtime. I've not seen a similar such warning when byte-compiling files that redefine other functions formally globally defined from some other place. AFAIK this only occurs with the CL's. > > The occurrence of the message in this case seems like a bug. > I don't have the impression that this is a bug per se. Its fairly clear looking at the sources of emacs-lisp/bytecomp.el that this is an intended (albeit unfortunate) outcome of `byte-compile-cl-warn', `byte-compile-cl-file-p', `byte-compile-eval'. What I find troubling is that: - the warning occurs opaquely and separate from the locus of its intended target (it affects the user regardless of whether she is the package author); - the distinction w/re the "global names" is made specific to CL at the byte-compiler level. With regards the latter my impression is that the distinction is made manifest at such a low-level _because_ it is primarily a philosophical/political design-decision rather than as a requirement of the LispMachine. What is irksome is that the distinction, being at once low-level and by proxy cumulatively entrenched, both allows and promotes a conflation of the design-decision aspects of the runtime ban with the functional requirements of the LispMachine in such a way as to disincentivise efforts to attempt decoupling the historically abstract vs. any contemporary practical concerns and intentions around a CL feature(s). Whether this outcome has arisen from a conscious intent/desire to prevent/deter incorporation of Common-Lisp like features into Emacs Lisp or is the only an inadverdent effect the result is the same. -- /s_P\ ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-09 0:29 ` MON KEY @ 2010-10-10 5:09 ` Richard Stallman 0 siblings, 0 replies; 55+ messages in thread From: Richard Stallman @ 2010-10-10 5:09 UTC (permalink / raw) To: MON KEY; +Cc: emacs-devel > The occurrence of the message in this case seems like a bug. > I don't have the impression that this is a bug per se. Its fairly clear looking at the sources of emacs-lisp/bytecomp.el that this is an intended (albeit unfortunate) outcome of `byte-compile-cl-warn', That sounds like a bug to me. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-04 2:03 ` Richard Stallman 2010-10-04 5:51 ` MON KEY @ 2010-10-04 17:33 ` Daniel Colascione 2010-10-05 9:55 ` Richard Stallman 1 sibling, 1 reply; 55+ messages in thread From: Daniel Colascione @ 2010-10-04 17:33 UTC (permalink / raw) To: rms; +Cc: MON KEY, emacs-devel On 10/3/2010 7:03 PM, Richard Stallman wrote: > Whatever the current/existing rationales may be, surely _some_ will > cease to be relevant by any reasonably sane justification in lieu of > lexically scoped environments. > > I don't think that relates to this issue. > This issue is about global names. > _What_ global names? cl.el is _already_ widely used. What symbols actually cause a problem _in practice_, _today_? ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-04 17:33 ` Daniel Colascione @ 2010-10-05 9:55 ` Richard Stallman 2010-10-05 10:20 ` Helmut Eller ` (4 more replies) 0 siblings, 5 replies; 55+ messages in thread From: Richard Stallman @ 2010-10-05 9:55 UTC (permalink / raw) To: Daniel Colascione; +Cc: monkey, emacs-devel _What_ global names? cl.el is _already_ widely used. What symbols actually cause a problem _in practice_, _today_? How would I know? We're talking about user's own programs here. The fact that many programmers use cl.el is not conclusive. Those programmers won't use cl names for anything else -- others might. Meanwhile, there is a further issue. If we move these symbols into the standard Elisp, we need to document them in the Lisp Reference manual. We could certainly do that, with some work. But it would also make the Elisp manual bigger and more expensive. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-05 9:55 ` Richard Stallman @ 2010-10-05 10:20 ` Helmut Eller 2010-10-05 18:27 ` Eli Zaretskii 2010-10-06 23:41 ` Richard Stallman 2010-10-05 13:07 ` Ted Zlatanov ` (3 subsequent siblings) 4 siblings, 2 replies; 55+ messages in thread From: Helmut Eller @ 2010-10-05 10:20 UTC (permalink / raw) To: emacs-devel * Richard Stallman [2010-10-05 09:55] writes: > Meanwhile, there is a further issue. If we move these symbols into > the standard Elisp, we need to document them in the Lisp Reference > manual. We could certainly do that, with some work. But it would > also make the Elisp manual bigger and more expensive. There is already a manual in doc/misc/cl.texi. Helmut ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-05 10:20 ` Helmut Eller @ 2010-10-05 18:27 ` Eli Zaretskii 2010-10-06 23:41 ` Richard Stallman 1 sibling, 0 replies; 55+ messages in thread From: Eli Zaretskii @ 2010-10-05 18:27 UTC (permalink / raw) To: Helmut Eller; +Cc: emacs-devel > From: Helmut Eller <eller.helmut@gmail.com> > Date: Tue, 05 Oct 2010 12:20:45 +0200 > > * Richard Stallman [2010-10-05 09:55] writes: > > > Meanwhile, there is a further issue. If we move these symbols into > > the standard Elisp, we need to document them in the Lisp Reference > > manual. We could certainly do that, with some work. But it would > > also make the Elisp manual bigger and more expensive. > > There is already a manual in doc/misc/cl.texi. Which is not part of the ELisp manual. Richard's concern is for the ELisp manual growing too large and too expensive, not with the need to write the relevant chapters. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-05 10:20 ` Helmut Eller 2010-10-05 18:27 ` Eli Zaretskii @ 2010-10-06 23:41 ` Richard Stallman 2010-10-07 15:04 ` Ted Zlatanov 2010-10-07 15:17 ` Karl Fogel 1 sibling, 2 replies; 55+ messages in thread From: Richard Stallman @ 2010-10-06 23:41 UTC (permalink / raw) To: Helmut Eller; +Cc: emacs-devel > Meanwhile, there is a further issue. If we move these symbols into > the standard Elisp, we need to document them in the Lisp Reference > manual. We could certainly do that, with some work. But it would > also make the Elisp manual bigger and more expensive. There is already a manual in doc/misc/cl.texi. It would need to be integrated into the Lisp Reference Manual to make that manual do its job. And maybe partly rewritten to make its style fit (I have not checked how much of that would be needed). ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-06 23:41 ` Richard Stallman @ 2010-10-07 15:04 ` Ted Zlatanov 2010-10-07 15:17 ` Karl Fogel 1 sibling, 0 replies; 55+ messages in thread From: Ted Zlatanov @ 2010-10-07 15:04 UTC (permalink / raw) To: emacs-devel On Wed, 06 Oct 2010 19:41:13 -0400 Richard Stallman <rms@gnu.org> wrote: >> Meanwhile, there is a further issue. If we move these symbols into >> the standard Elisp, we need to document them in the Lisp Reference >> manual. We could certainly do that, with some work. But it would >> also make the Elisp manual bigger and more expensive. RS> There is already a manual in doc/misc/cl.texi. RS> It would need to be integrated into the Lisp Reference Manual RS> to make that manual do its job. And maybe partly rewritten RS> to make its style fit (I have not checked how much of that RS> would be needed). Many times features are either unexplained or it says to "look at the examples." For people who know CL or have experience with cl.el already it's a pretty good reference but for me the first time was a lot of back and forth browsing. In terms of organization it's pretty good. I found it very readable when I looked at it. But if it's integrated within the larger manual, many functions will need to at least get linked in the relevant sections (e.g. cl.el sequence functions should be mentioned in the "(elisp) Sequences Arrays Vectors" node). Ted ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-06 23:41 ` Richard Stallman 2010-10-07 15:04 ` Ted Zlatanov @ 2010-10-07 15:17 ` Karl Fogel 2010-10-09 2:13 ` Richard Stallman 1 sibling, 1 reply; 55+ messages in thread From: Karl Fogel @ 2010-10-07 15:17 UTC (permalink / raw) To: rms; +Cc: Helmut Eller, emacs-devel Richard Stallman <rms@gnu.org> writes: >It would need to be integrated into the Lisp Reference Manual >to make that manual do its job. And maybe partly rewritten >to make its style fit (I have not checked how much of that >would be needed). Is the size of the reference manual really a concern anymore? I ordered a print one years ago; I never use it. I use exclusively the electronic copy, and suspect the same is true of most (perhaps even all?) Emacs Lisp programmers. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-07 15:17 ` Karl Fogel @ 2010-10-09 2:13 ` Richard Stallman 0 siblings, 0 replies; 55+ messages in thread From: Richard Stallman @ 2010-10-09 2:13 UTC (permalink / raw) To: Karl Fogel; +Cc: eller.helmut, emacs-devel Is the size of the reference manual really a concern anymore? Yes -- we sell them and we want to keep selling them. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-05 9:55 ` Richard Stallman 2010-10-05 10:20 ` Helmut Eller @ 2010-10-05 13:07 ` Ted Zlatanov 2010-10-06 23:41 ` Richard Stallman 2010-10-05 18:26 ` Eli Zaretskii ` (2 subsequent siblings) 4 siblings, 1 reply; 55+ messages in thread From: Ted Zlatanov @ 2010-10-05 13:07 UTC (permalink / raw) To: emacs-devel On Tue, 05 Oct 2010 05:55:45 -0400 Richard Stallman <rms@gnu.org> wrote: RS> The fact that many programmers use cl.el is not conclusive. Those RS> programmers won't use cl names for anything else -- others might. My experience as a spectator has been that almost all ELisp programmers are aware of cl.el and don't redefine its functions. FWIW, I am strongly in favor of making cl.el a first-class citizen. The pain of the promotion is outweighed by the benefits IMO. RS> Meanwhile, there is a further issue. If we move these symbols into RS> the standard Elisp, we need to document them in the Lisp Reference RS> manual. We could certainly do that, with some work. But it would RS> also make the Elisp manual bigger and more expensive. I hope that's not an impediment. Maybe it can be an optional extra volume to the ELisp manual. Ted ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-05 13:07 ` Ted Zlatanov @ 2010-10-06 23:41 ` Richard Stallman 2010-10-07 9:20 ` Daniel Colascione 0 siblings, 1 reply; 55+ messages in thread From: Richard Stallman @ 2010-10-06 23:41 UTC (permalink / raw) To: Ted Zlatanov; +Cc: emacs-devel I hope that's not an impediment. Maybe it can be an optional extra volume to the ELisp manual. If they will be used often, putting them in an extra volume is not a good solution. Likewise, omitting them from the printed edition is not a solution. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-06 23:41 ` Richard Stallman @ 2010-10-07 9:20 ` Daniel Colascione 2010-10-08 5:47 ` Richard Stallman 0 siblings, 1 reply; 55+ messages in thread From: Daniel Colascione @ 2010-10-07 9:20 UTC (permalink / raw) To: rms; +Cc: Ted Zlatanov, emacs-devel [-- Attachment #1: Type: text/plain, Size: 557 bytes --] On 10/6/10 4:41 PM, Richard Stallman wrote: > I hope that's not an impediment. Maybe it can be an optional extra > volume to the ELisp manual. > > If they will be used often, putting them in an extra volume > is not a good solution. > > Likewise, omitting them from the printed edition is not a solution. If any new feature must be documented, and the documentation cannot exceed a certain size, then new features cannot be added. Are you proposing to cap the size of Emacs? Or does this logic only apply to things named "cl.el"? [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-07 9:20 ` Daniel Colascione @ 2010-10-08 5:47 ` Richard Stallman 0 siblings, 0 replies; 55+ messages in thread From: Richard Stallman @ 2010-10-08 5:47 UTC (permalink / raw) To: Daniel Colascione; +Cc: tzz, emacs-devel If any new feature must be documented, and the documentation cannot exceed a certain size, then new features cannot be added. Are you proposing to cap the size of Emacs? Or does this logic only apply to things named "cl.el"? Obviously neither one. You are not responding to what I said. Instead you invented two ways of taking it to an extreme, and attacked them. That's mean-spirited as well as unconstructive. There are many differences between possible new Emacs Lisp features as regards how much documentation they need and where it is useful to put that documentation. Some features are rather specialized and can perfectly well be left out of the printed manual. For others the needed documentation can be short. CL, however, is complex and would be meant for widespread use in all sorts of Lisp programs. Thus, this is a significant issue for CL and might be insignificant for other extensions. We might consider installing just part of the CL features and looking for a concise (but clear) way to document them. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-05 9:55 ` Richard Stallman 2010-10-05 10:20 ` Helmut Eller 2010-10-05 13:07 ` Ted Zlatanov @ 2010-10-05 18:26 ` Eli Zaretskii 2010-10-06 0:29 ` MON KEY 2010-10-06 8:04 ` Stephen J. Turnbull 4 siblings, 0 replies; 55+ messages in thread From: Eli Zaretskii @ 2010-10-05 18:26 UTC (permalink / raw) To: rms; +Cc: monkey, dan.colascione, emacs-devel > From: Richard Stallman <rms@gnu.org> > Date: Tue, 05 Oct 2010 05:55:45 -0400 > Cc: monkey@sandpframing.com, emacs-devel@gnu.org > > Meanwhile, there is a further issue. If we move these symbols into > the standard Elisp, we need to document them in the Lisp Reference > manual. We could certainly do that, with some work. But it would > also make the Elisp manual bigger and more expensive. That issue can be solved like we did in the Emacs manual: have parts of it that are only generated in the on-line formats, but not in the printed copy. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-05 9:55 ` Richard Stallman ` (2 preceding siblings ...) 2010-10-05 18:26 ` Eli Zaretskii @ 2010-10-06 0:29 ` MON KEY 2010-10-08 2:07 ` Christian Ohler 2010-10-06 8:04 ` Stephen J. Turnbull 4 siblings, 1 reply; 55+ messages in thread From: MON KEY @ 2010-10-06 0:29 UTC (permalink / raw) To: rms; +Cc: eliz, dan.colascione, ohler+emacs, emacs-devel On Mon, Oct 4, 2010 at 1:33 PM, Daniel Colascione <dan.colascione@gmail.com> wrote: > On 10/3/2010 7:03 PM, Richard Stallman wrote: >> Whatever the current/existing rationales may be, surely _some_ will >> cease to be relevant by any reasonably sane justification in lieu of >> lexically scoped environments. >> >> I don't think that relates to this issue. >> This issue is about global names. >> > > _What_ global names? cl.el is _already_ widely used. What symbols > actually cause a problem _in practice_, _today_? > Its tautological... CL symbols which name a function exist with global names and therefor can not be allowed to pollute the global name space. As indicated with my earlier example, when `byte-compile-warnings' is non-nil and '(byte-compile-warning-enabled-p 'cl-functions)' returns non-nil (per a symbol's membership in `byte-compile-cl-functions'), then byte-compilation signals a warning that the symbol was called at runtime (regardless of when/where that symbol was actually defined). IOW, the CL functions exists in a state of privileged limbo in that they can not be called at runtime but nor are they allowed to be redefined at compile time... IIUC this cycle is a product of the current byte-compilers relatively flat environment which is what prompted the assertion: ,---- | Whatever the current/existing rationales may be, surely _some_ will | cease to be relevant by any reasonably sane justification in lieu of | lexically scoped environments. `---- The lexbind promotes less flat environments with its `heap environment vectors' see for example the variables: `byte-compile-lexical-environment', `byte-compile-current-heap-environment', `byte-compile-current-num-closures', `byte-stack-ref', `byte-stack-set', `byte-stack-set2', `byte-vec-ref', `byte-vec-set', `byte-discardN', `byte-discardN-preserve-tos' And employs an entirely different compile time expansion of macro environments e.g. the constant `byte-compile-initial-macro-environment'. The lexbind byte-compiler handles these environments and those established by lexical closures in new ways. This includes modification of the existing `byte-compile-lambda' with a significantly new re-direction through `byte-compile-closure', `byte-compile-make-closure', `byte-compile-make-lambda-lexenv', etc. Indeed, whenever an anonymous function occurs inside a lexical-binding all compile-time variables are affected by use of separate 'heapenv' heap environment vectors. Whatever. I'm sure some of the above is very much in flux in Stefan/Miles' private branches and likely to change before those emerge (presumably circa Spring 2011). The intent of my above referenced query is to learn how much of the global names argument will remain relevant for those CL symbols (and their locals) which currently "pollute" the global names but which (if adapted in lieu of lexbind) might have some not insignificant portion of this pollution encapsulated with closed over 'lexenv' environments including any byte-compiler optimizations over the 'lexvars' of these environments. More specifically, if some aspect(s) of the above are indeed possible/reasonable and the pollution might be reduced, I'm curious to learn if those CL functions which accept keywords could be abstracted in such a way that they might be included in core without constraints on these necessarily being "keywordless" but instead that there be a proviso for requisite compile-time analysis capable of determining whether the function body expects non-keyword arguments or instead a keyword variant. This would: - Allow backwards compatibility with existing uses of CL functions; - Provide an opportunity to revisit certain places where the existing cl.el implementation is regarded deficient/sub-optimal; - Provide 3rd party developers the opportunity adapt existing code to use a 'lighter' non-keyword CL variants where appropriate; - Acknowledges Stefan's distaste of maintaining distinct symbol-names for the Emacs lisp core function vs the CL counterpart, e.g. push, pop, dotimes, dolist, etc.; - Ease documentation concerns because portions of the existing CL info could be incorporated without requiring that all references to the keyword usage be gutted. Instead, documentation for the default non-keyword version would be added along with clarification of the differences. Given that Emacs installs with the cl.info the this should help keep the expense of documentation overhead down. (Assumes there aren't lingering arm-waving intentions about some vague copyright restriction w/re the cl.info manual and the ANSI spec); It is apropos the possibility that some of the above hypotheticals might have relevance/traction that I asserted previously: ,---- | It is important that those willing to revisit/revise the cl.el | deficiencies have a clear roadmap/guideline as to what is acceptable, | why, and what the sane justifications for these guidelines are. `---- Right now there are numerous alternative and (functionally divergent) implementations of the CL functions which often have been written to not trigger signalling of CL related runtime byte-compiler warnings. I've pointed out some that are already in core. Note, none of these appear to have been written in a spirit of: "Oh, I wrote this because I don't want all of those CL features." Indeed, most of the packages which employ cl feature duplication do rely elsewhere on CL macros, but these don't trigger the runtime warnings. So, as an example, one finds that prior to Bzr-98091 of 2009-10-11 eieio.el's `eieio-add-new-slot' called `union' twice, each time inside deeply nested conditionals. These `union' calls were responsible for informing the adjustment of class slot attributes pertinent to custom-group classes. Who knows if anyone is using this stuff (what with it being custom and all). Regardless, both of these calls have since been adapted by virtue of a "manual inlining"... The first such `union' call involves a tweak of an index into `class-public-custom-group'. It is triggered when `eieio-add-new-slot' optional arg DEFAULTOVERRIDE is non-nil. The second also is a similar tweak triggered in the same manner but instead finds a takes a union of an index into `class-class-allocation-custom-group'. Now, presumably user code won't rely on these tweaks occurring all that frequently as the DEFAULTOVERRIDE arg is the first optional arg in the `eieio-add-new-slot' lambda-list. Indeed, it follows 11 other obviously more important parameters e.g.: (1- (length '(newc a d doc type cust label custg print prot init alloc &optional defaultoverride skipnil))) and can't possibly be all that important in its priveleged 12th position given that the _eleven_ preceding args are mandatory... "Nah, we don't need no stinkin' keywords." Or not. Instance one of `union's demise by duplication: ,---- lisp/emacs-lisp/eieio.el `eieio-add-new-slot' @Bzr-98018 | (when custg | (let ((where-groups | (nthcdr num (aref newc class-public-custom-group)))) | (setcar where-groups | (union (car where-groups) | (if (listp custg) custg (list custg)))))) `---- ,---- lisp/emacs-lisp/eieio.el `eieio-add-new-slot' @Bzr-101790 | (when custg | (let* ((groups | (nthcdr num (aref newc class-public-custom-group))) | (list1 (car groups)) | (list2 (if (listp custg) custg (list custg)))) | (if (< (length list1) (length list2)) | (setq list1 (prog1 list2 (setq list2 list1)))) | (dolist (elt list2) | (unless (memq elt list1) | (push elt list1))) | (setcar groups list1))) `---- Note, the only discernible difference between the chunks above and those below are the let bindings of the local `groups` var to an index into `class-class-allocation-custom-group' instead of `class-public-custom-group', otherwise they are identical. Instance two of `union's demise by duplication: ,---- lisp/emacs-lisp/eieio.el `eieio-add-new-slot' @Bzr-98018 | (when custg | (let ((where-groups | (nthcdr num (aref newc class-class-allocation-custom-group)))) | (setcar where-groups | (union (car where-groups) | (if (listp custg) custg (list custg)))))) `---- ,---- lisp/emacs-lisp/eieio.el `eieio-add-new-slot' @Bzr-101790 | (when custg | (let* ((groups | (nthcdr num (aref newc class-class-allocation-custom-group))) | (list1 (car groups)) | (list2 (if (listp custg) custg (list custg)))) | (if (< (length list1) (length list2)) | (setq list1 (prog1 list2 (setq list2 list1)))) | (dolist (elt list2) | (unless (memq elt list1) | (push elt list1))) | (setcar groups list1))) `---- Now for a game of "one of these things looks alot like the other one": ,---- lisp/emacs-lisp/cl-seq.el `union' @Bzr-101804 | | (cond ((null cl-list1) cl-list2) ((null cl-list2) cl-list1) | ((equal cl-list1 cl-list2) cl-list1) | (t | (or (>= (length cl-list1) (length cl-list2)) | (setq cl-list1 (prog1 cl-list2 (setq cl-list2 cl-list1)))) | (while cl-list2 | (if (or cl-keys (numberp (car cl-list2))) | (setq cl-list1 | (apply 'adjoin (car cl-list2) cl-list1 cl-keys)) | (or (memq (car cl-list2) cl-list1) | (push (car cl-list2) cl-list1))) | (pop cl-list2)) | cl-list1)) | `---- In the absence of a change to the current runtime ban more of the above will continue to spring up. Now, no doubt when Chong Yidong must be bothered to implement this sort of hackery one can expect a _correct_ hack. Right? Its not like the above isn't mostly a copy/paste job into an unbelievably deeply chunk of nested nastiness... The "problem" though is that many such like workarounds aren't instrumented courtesy Chong/Stefan/Richard et al, but instead by 3rd parties whom none-the-less _are_ making attempts to comply with the CL function runtime ban. It isn't enough for emacs-devels to dismiss those parties (as they sometimes do) with: "Well, either ignore the byte-compiler warnings if they bother you so much or don't use the CL features in your library" This is insults both the 3rd party developer and any party whom attempts installing the third party library. When byte-compilation of the 3rd party code signals a bunch of byte-compiler warnings it casts doubt or creates fear and uncertainty and may make it appear as if the library is deficient/suspect. All else being equal, the cumulative effect of these byte-compiler warnings is a form of discriminatory rankism which privileges the Emacs core libraries which in turn promotes further entrenchment of the CL runtime ban, e.g.: "None of the core libraries require/rely on CL functions which pollute the global names in order to get things done." Indeed, they don't - most likely they just implement it in C instead. This isn't an option to 3rd party developers. So, to avoid the _appearance_ of being "unclean" 3rd parties often either: - copy the CL function definitions verbatim (which _is_ itself a colossal pollution of the "global names"); - attempt to (re)implement the portions of the CL feature set they would otherwise use were the ban not in place It is clear that both of the above choices are and have been occurring. With regards the re-implementation approach, this is where the CL runtime ban fails to benefit both the community of Emacs users and 3rd party authors in the "real world" because (re)implementing any subset of the CL feature is: - hard to accomplish in the absence of runtime usage of the CL features, i.e. the act itself lands one in the Turing Tar Pit; - a waste of energy rebuilding the existent usable, distributed, and tested featureset esp. as it at least attempts adherence to a formally peer reviewed specification; - likely won't benefit from the same byte-compiler optimizations as a cl-*.el counterpart; - apt to error in unexpected/unforeseen non-standard ways; This is grossly unfortunate because it is clear that despite these obstacles 3rd parties do endeavor re-implementing workarounds to the CL runtime ban despite Philip Greenspun's "Tenth Rule" leering back at them. The gross aspect of this circumstance being that "Greenspun's Tenth" is most likely a precept well known to the unfortunate attempting to recapture some semblance of the Common Lisp so denied... By way of an example we have the following: ,---- | From: Stefan Monnier | Subject: Re: testing framework and package.el | Date: Tue, 28 Sep 2010 00:57:51 +0200 | (URL `http://lists.gnu.org/archive/html/emacs-devel/2010-09/msg01500.html') | | IIRC we've agreed to try and install ERT, either on elpa or in Emacs | itself, and then try and move the few tests we already have | scattered about to use ERT. But I haven't heard much about it | recently `---- Taking a look at ert.el package on Christian Ohler's git repo: (URL `git://github.com/ohler/ert.git') one finds yet more CL feature duplication attempts. These presumably queued up for inclusion in Emacs proper in the not so distant future. Below are the CL "duplicate" features from ert/lisp/emacs-lisp/ert.el The features `ert--cl-do-remf' and `ert--remprop' are verbatim copies of `cl-do-remf'. The features `ert--remove-if-not', `ert--intersection', `ert--set-difference', `ert--set-difference-eq', and `ert--union' are keywordless re-implementations of CL features which leverage the `loop' macro to mimic the CL features `intersection', `set-difference', and `union'. It should be noted however that (with the exception of `ert--union') these are not at all faithful duplicates of either the CL features or their ANSI brethren as they fail to check that their args are proper-lists/sequences... Now, I'm given to believe that Ohler is not only an accomplished hack, but also prob. one well aware of the Common Lisp ANSI spec. So his floundering on the proper-list/proper-seq thing is prob. indicative of something. Does Ohler believe that his CL duplicates are better for their non-conformance and breaking with both the semantics of both the CL features and the Common Lisp features? Maybe he finds his duplicates achieve a desirable performance gain. Or, maybe he just doesn't feel it worth the trouble to rewrite _all_ of cl*.el. This said, that ERT is slated as the "blessed" Emacs unit test framework begs a more important question. If Ohler implemented his CL feature duplications as a kludge would he have simply done a (require 'cl) and been done with it were it not for the CL runtime ban? And if so, would ERT be better/more correct by so doing? Whatever. Say hello to the latest iteration of a Lisper doing his best to suffer a foolish policy. ,---- ert/lisp/emacs-lisp/ert.el (URL `http://github.com/ohler/ert') | | | (defun ert--cl-do-remf (plist tag) | "Copy of `cl-do-remf'. Modify PLIST by removing TAG." | (let ((p (cdr plist))) | (while (and (cdr p) (not (eq (car (cdr p)) tag))) | (setq p (cdr (cdr p)))) | (and (cdr p) (progn (setcdr p (cdr (cdr (cdr p)))) t)))) | | (defun ert--remprop (sym tag) | "Copy of `cl-remprop'. Modify SYM's plist by removing TAG." | (let ((plist (symbol-plist sym))) | (if (and plist (eq tag (car plist))) | (progn (setplist sym (cdr (cdr plist))) t) | (ert--cl-do-remf plist tag)))) | | ;; :NOTE Vector agnostic. | ;; (ert--remove-if-not 'stringp ["a" "b" c]) ;=> nil | ;; (ert--remove-if-not 'stringp '("a" "b" c)) ;=> ("a" "b") | ;; (remove-if-not 'stringp ["a" "b" c]) ;=> ["a" "b"] | ;; (remove-if-not 'stringp '("a" "b" c)) ;=> ("a" "b") | (defun ert--remove-if-not (ert-pred ert-list) | "A reimplementation of `remove-if-not'. | ERT-PRED is a predicate, ERT-LIST is the input list." | (loop for ert-x in ert-list | if (funcall ert-pred ert-x) | collect ert-x)) | | ;; :NOTE `set-difference' w/ Common Lisp's default implicit 'eql test. | ;; Mostly equivalent to cl-seq.el's `intersection' | ;; (intersection '(a b) '(c a) :test 'eql) | ;; But, does not check that args are proper lists: | ;; (ert--intersection '(a . c) '(b d)) ;=> nil | ;; (intersection '(a . c) '(b d)) ;=> (wrong-type-argument listp c) | (defun ert--intersection (a b) | "A reimplementation of `intersection'. Intersect the sets A and B. | Elements are compared using `eql'." | (loop for x in a | if (memql x b) | collect x)) | | ;; :NOTE `set-difference' w/ Common Lisp's default implicit 'eql test. | ;; Mostly equivalent to cl-seq.el's `set-difference': | ;; (set-difference a b :test 'eql) | ;; But, does not check that args are proper lists: | ;; (ert--set-difference '(a . c) '(b d)) ;=> (a) | ;; (set-difference '(a . c) '(b d) :test 'eql) | ;; => (wrong-type-argument listp c) | (defun ert--set-difference (a b) | "A reimplementation of `set-difference'. | Subtract the set B from the set A. | Elements are compared using `eql'." | (loop for x in a | unless (memql x b) | collect x)) | | ;; :NOTE This is roughly cl.el's `set-difference' w/ the implicit | ;; 'eq test. | ;; Mostly equivalent to Common Lisp's: (set-difference a b :test 'eq) | ;; But, does not check that args are proper lists: | ;; (ert--set-difference-eq '(a . c) '(b d)) ;=> (a) | ;; (set-difference '(a . c) '(b d)) ;=> (wrong-type-argument listp c) | (defun ert--set-difference-eq (a b) | "A reimplementation of `set-difference'. | Subtract the set B from the set A. | Elements are compared using `eq'." | (loop for x in a | unless (memq x b) | collect x)) | | ;; :NOTE Unlike above doesn't error when args not proper lists | ;; (ert--union '(a . c) '(b d)) ;=> (wrong-type-argument listp c) | (defun ert--union (a b) | "A reimplementation of `union'. | Compute the union of the sets A and B. | Elements are compared using `eql'." | (append a (ert--set-difference b a))) | | (eval-and-compile | (defvar ert--gensym-counter 0)) | | ;; :NOTE Does note accept integer for optional arg PREFIX. | (eval-and-compile | (defun ert--gensym (&optional prefix) | "Only allows string PREFIX, not compatible with CL." | (unless prefix (setq prefix "G")) | (make-symbol (format "%s%s" | prefix | (prog1 ert--gensym-counter | (incf ert--gensym-counter)))))) | | ;; :NOTE Could chang parameter list to ( ... &optional key test) | (defun* ert--remove* (x list &key key test) | "Does not support all the keywords of remove*." | (unless key (setq key #'identity)) | (unless test (setq test #'eql)) | (loop for y in list | unless (funcall test x (funcall key y)) | collect y)) | | (defun ert--mismatch (a b) | "Return index of first element that differs between A and B. | Like `mismatch'. Uses `equal' for comparison." | (cond ((or (listp a) (listp b)) | (ert--mismatch (ert--coerce-to-vector a) | (ert--coerce-to-vector b))) | ((> (length a) (length b)) | (ert--mismatch b a)) | (t | (let ((la (length a)) | (lb (length b))) | (assert (arrayp a) t) | (assert (arrayp b) t) | (assert (<= la lb) t) | (loop for i below la | when (not (equal (aref a i) (aref b i))) return i | finally (return (if (/= la lb) | la | (assert (equal a b) t) | nil))))))) | | (defun ert--subseq (seq start &optional end) | "Returns a subsequence of SEQ from START to END." | (when (char-table-p seq) (error "Not supported")) | (let ((vector (substring (ert--coerce-to-vector seq) start end))) | (etypecase seq | (vector vector) | (string (concat vector)) | (list (append vector nil)) | (bool-vector (loop with result = (make-bool-vector (length vector) nil) | for i below (length vector) do | (setf (aref result i) (aref vector i)) | finally (return result))) | (char-table (assert nil))))) | | (defun ert--special-operator-p (thing) | "Return non-nil if THING is a symbol naming a special operator." | (and (symbolp thing) | (let ((definition (indirect-function thing t))) | (and (subrp definition) | (eql (cdr (subr-arity definition)) 'unevalled))))) | `---- -- /s_P\ ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-06 0:29 ` MON KEY @ 2010-10-08 2:07 ` Christian Ohler 2010-10-08 2:18 ` Miles Bader 0 siblings, 1 reply; 55+ messages in thread From: Christian Ohler @ 2010-10-08 2:07 UTC (permalink / raw) To: MON KEY; +Cc: eliz, dan.colascione, rms, emacs-devel On 6/10/10 9:59, MON KEY wrote: > Does Ohler believe that his CL duplicates are better for their > non-conformance and breaking with both the semantics of both the CL > features and the Common Lisp features? Maybe he finds his duplicates > achieve a desirable performance gain. Or, maybe he just doesn't feel it > worth the trouble to rewrite _all_ of cl*.el. Because a run-time dependency on cl.el would make it hard for ERT to become part of Emacs and triggers distracting warnings, I reimplemented the subset of CL that ERT requires. I don't think this subset is better than cl.el, and I haven't checked which implementation is faster. > If Ohler implemented his CL feature duplications as a kludge would he > have simply done a (require 'cl) and been done with it were it not for > the CL runtime ban? Yes. > And if so, would ERT be better/more correct by so doing? Better? Probably, since I could have spent my time on other features, and the definitions in cl.el may well be faster than my reimplementations. More correct? I'm not sure. You are examining the behavior of `ert--remove-if-not' etc. for Common Lisp compliance; but there is no reason why it would have to be, since these functions are just private utilities in ERT. They only provide the subset of CL functionality that ERT requires. They either document that they only work on lists, or signal an error on sequence types that they don't support. The check for dotted lists that you are looking for is guaranteed in Common Lisp only in what Common Lisp calls "safe code". In safe code, Common Lisp also guarantees this check for `loop' and `member'; but `loop' and `member' in Emacs Lisp don't have this check. So, ERT's CL-like utility functions behave like unsafe code in this regard, just like other Emacs Lisp functions. If you have a concrete reason to believe that these functions lead to bugs in ERT, please let me know. Reimplementing these CL utility functions (in http://github.com/ohler/ert/commit/cdc3dfad4779cb9421a6711f6ef7be522ca8e5b0 ) was actually only part of the work I had to do to avoid a run-time dependency on CL. I also had to implement a special-purpose replacement for `typep' in http://github.com/ohler/ert/commit/bde37b42d0187356cfd747d5ec245b30690c2fcf , and the trickiest part was making ERT's call to `macroexpand' work regardless of whether cl.el is loaded, see http://github.com/ohler/ert/commit/f481a5c2b38a8ccd06b9ddd9c7243409fb583ea2 : If cl.el is loaded, ERT needs to pass two arguments to `macroexpand', only one otherwise. The solution is simple, but figuring out that this problem exists took me a while. Christian. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-08 2:07 ` Christian Ohler @ 2010-10-08 2:18 ` Miles Bader 2010-10-08 3:15 ` Christian Ohler 0 siblings, 1 reply; 55+ messages in thread From: Miles Bader @ 2010-10-08 2:18 UTC (permalink / raw) To: Christian Ohler; +Cc: eliz, MON KEY, dan.colascione, rms, emacs-devel Christian Ohler <ohler+emacs@fastmail.net> writes: > : If cl.el is loaded, ERT needs to pass two arguments to > macroexpand', only one otherwise. The solution is simple, but > figuring out that this problem exists took me a while. The normal (non-cl) macroexpand takes the same arguments, so why do you need to make a distinction? -Miles -- ((lambda (x) (list x x)) (lambda (x) (list x x))) ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-08 2:18 ` Miles Bader @ 2010-10-08 3:15 ` Christian Ohler 0 siblings, 0 replies; 55+ messages in thread From: Christian Ohler @ 2010-10-08 3:15 UTC (permalink / raw) To: Miles Bader; +Cc: eliz, MON KEY, dan.colascione, rms, emacs-devel On 8/10/10 11:48, Miles Bader wrote: > Christian Ohler<ohler+emacs@fastmail.net> writes: >> : If cl.el is loaded, ERT needs to pass two arguments to >> macroexpand', only one otherwise. The solution is simple, but >> figuring out that this problem exists took me a while. > The normal (non-cl) macroexpand takes the same arguments, so why do > you need to make a distinction? It takes an environment argument, but I don't know where to get an environment value if cl.el is not loaded. Originally, I defined my macros with defmacro* and &environment, but such macros can only be expanded when cl.el is loaded, since their definition references `cl-macro-environment', which is only bound with cl.el. So I got rid of &environment and instead read `cl-macro-environment' directly if it is bound. It's quite possible that this solution is not quite right or that something even simpler works; I don't understand these mechanisms in detail. Looking at it again, I wonder if the following statement in one of ERT's comments is correct: ;; If `cl-macroexpand' isn't bound, the code that we're ;; compiling doesn't depend on cl and thus doesn't need an ;; environment arg for `macroexpand'. Is it true that we don't need an environment arg? Or do we have to get the byte-compiler's environment and pass it in? Christian. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-05 9:55 ` Richard Stallman ` (3 preceding siblings ...) 2010-10-06 0:29 ` MON KEY @ 2010-10-06 8:04 ` Stephen J. Turnbull 2010-10-06 9:20 ` David Kastrup 4 siblings, 1 reply; 55+ messages in thread From: Stephen J. Turnbull @ 2010-10-06 8:04 UTC (permalink / raw) To: rms; +Cc: monkey, Daniel Colascione, emacs-devel Richard Stallman writes: > The fact that many programmers use cl.el is not conclusive. Those > programmers won't use cl names for anything else -- others might. XEmacs has been dumping cl for at least a decade, with no complaints I can recall. FWIW YMMV ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: moving more cl seq/mapping support into core 2010-10-06 8:04 ` Stephen J. Turnbull @ 2010-10-06 9:20 ` David Kastrup 0 siblings, 0 replies; 55+ messages in thread From: David Kastrup @ 2010-10-06 9:20 UTC (permalink / raw) To: emacs-devel "Stephen J. Turnbull" <stephen@xemacs.org> writes: > Richard Stallman writes: > > > The fact that many programmers use cl.el is not conclusive. Those > > programmers won't use cl names for anything else -- others might. > > XEmacs has been dumping cl for at least a decade, with no complaints I > can recall. FWIW YMMV My main complaint is that I usually try fixing comprehension problems by reading the source. cl's existing DOC strings are often semiobfuscate, requiring a certain degree of "common Lisp" thinkage in order to make sense of. The cl code itself is more or less completely inscrutable. Partly because of its nature of macro expansion, partly because of coding techniques/styles and internals that are neither explained with code comments nor self-explaining. It does not tie in nicely with Emacs Lisp and promotes a programming style that does not map straightforwardly to the Lisp machine and makes debugging and streamlining haphazard. My personal gut feeling would be to _first_ give Emacs well-working lexical binding. Then more or less reimplement cl from scratch. If things like keyword parsing would profit from supporting C functions, create those functions instead of fiddling with macros all around. Make sure that the bytecode has everything to support cl sanely rather than as a clever afterthought. -- David Kastrup ^ permalink raw reply [flat|nested] 55+ messages in thread
end of thread, other threads:[~2010-10-10 5:09 UTC | newest] Thread overview: 55+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-09-24 22:48 moving more cl seq/mapping support into core MON KEY 2010-09-25 5:13 ` Leo 2010-09-25 5:58 ` Miles Bader 2010-09-25 14:42 ` Drew Adams 2010-09-25 15:07 ` Leo 2010-09-25 15:23 ` Drew Adams 2010-09-25 15:30 ` Leo 2010-09-25 15:33 ` David Kastrup 2010-09-25 15:55 ` Drew Adams 2010-09-25 15:55 ` Drew Adams 2010-09-25 16:01 ` Leo 2010-10-01 0:33 ` Daniel Colascione 2010-09-25 21:26 ` Miles Bader 2010-09-26 10:37 ` Richard Stallman 2010-09-26 13:13 ` Leo 2010-09-26 19:32 ` Miles Bader 2010-09-27 6:27 ` Richard Stallman 2010-10-01 0:28 ` Daniel Colascione 2010-10-01 3:16 ` Miles Bader 2010-10-01 20:39 ` Daniel Colascione 2010-10-02 7:12 ` David Kastrup 2010-10-03 23:15 ` Stefan Monnier 2010-10-04 17:41 ` Daniel Colascione 2010-10-05 23:32 ` Stefan Monnier 2010-10-01 11:42 ` Richard Stallman 2010-10-01 20:36 ` Daniel Colascione 2010-10-01 11:42 ` Richard Stallman 2010-10-01 20:34 ` Daniel Colascione 2010-10-01 21:12 ` Chong Yidong 2010-09-27 19:07 ` MON KEY 2010-10-02 5:35 ` MON KEY 2010-10-04 2:03 ` Richard Stallman 2010-10-04 5:51 ` MON KEY 2010-10-06 5:21 ` Richard Stallman 2010-10-09 0:29 ` MON KEY 2010-10-10 5:09 ` Richard Stallman 2010-10-04 17:33 ` Daniel Colascione 2010-10-05 9:55 ` Richard Stallman 2010-10-05 10:20 ` Helmut Eller 2010-10-05 18:27 ` Eli Zaretskii 2010-10-06 23:41 ` Richard Stallman 2010-10-07 15:04 ` Ted Zlatanov 2010-10-07 15:17 ` Karl Fogel 2010-10-09 2:13 ` Richard Stallman 2010-10-05 13:07 ` Ted Zlatanov 2010-10-06 23:41 ` Richard Stallman 2010-10-07 9:20 ` Daniel Colascione 2010-10-08 5:47 ` Richard Stallman 2010-10-05 18:26 ` Eli Zaretskii 2010-10-06 0:29 ` MON KEY 2010-10-08 2:07 ` Christian Ohler 2010-10-08 2:18 ` Miles Bader 2010-10-08 3:15 ` Christian Ohler 2010-10-06 8:04 ` Stephen J. Turnbull 2010-10-06 9:20 ` David Kastrup
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.