* Some racism in emacs! @ 2003-06-01 6:05 Pascal Bourguignon 2003-06-01 7:41 ` John Paul Wallington 0 siblings, 1 reply; 6+ messages in thread From: Pascal Bourguignon @ 2003-06-01 6:05 UTC (permalink / raw) I'm wondering why when I compile a .el file, the byte-compiler does not issue any warning about my use of functions from ring.el such as: make-ring or ring-insert? Well, actually what's bothering me is these nasty, racist messages I get from the byte-compiler: Warning: Function `gensym' from cl package called at runtime Warning: Function `subseq' from cl package called at runtime etc... I can't see the difference between the functions defined in emacs/lisp/emacs-lisp/cl.el and those defined in emacs/lisp/emacs-lisp/ring.el Can you? -- __Pascal_Bourguignon__ http://www.informatimago.com/ ---------------------------------------------------------------------- Do not adjust your mind, there is a fault in reality. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Some racism in emacs! 2003-06-01 6:05 Some racism in emacs! Pascal Bourguignon @ 2003-06-01 7:41 ` John Paul Wallington 2003-06-02 6:42 ` Pascal Bourguignon 0 siblings, 1 reply; 6+ messages in thread From: John Paul Wallington @ 2003-06-01 7:41 UTC (permalink / raw) Pascal Bourguignon <spam@thalassa.informatimago.com> wrote: > Well, actually what's bothering me is these nasty, racist messages I > get from the byte-compiler: > > Warning: Function `gensym' from cl package called at runtime > Warning: Function `subseq' from cl package called at runtime > etc... > > > I can't see the difference between the functions defined in > emacs/lisp/emacs-lisp/cl.el and those defined in > emacs/lisp/emacs-lisp/ring.el > Can you? The cl library, like Common Lisp, is big and hard to subset. Amongst the Emacs Lisp Coding Conventions it is suggested: * Please don't require the `cl' package of Common Lisp extensions at run time. Use of this package is optional, and it is not part of the standard Emacs namespace. If your package loads `cl' at run time, that could cause name clashes for users who don't use that package. However, there is no problem with using the `cl' package at compile time, for the sake of macros. You do that like this: (eval-when-compile (require 'cl)) Hm. I think name clashes are largely a non-problem; a package author would be insane to define cl functions/macros incompatibly, wouldn't they? Ways to ameliorate this situation include splitting cl into several separate independent libraries, moving ultra-nifty bits into subr.el, or defining compiler macros for the more popular functions. If you just don't want to see the warnings then try frobbing `byte-compile-warnings' (untested). ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Some racism in emacs! 2003-06-01 7:41 ` John Paul Wallington @ 2003-06-02 6:42 ` Pascal Bourguignon 2003-06-02 9:46 ` John Paul Wallington 0 siblings, 1 reply; 6+ messages in thread From: Pascal Bourguignon @ 2003-06-02 6:42 UTC (permalink / raw) John Paul Wallington <jpw@gnu.org> writes: > The cl library, like Common Lisp, is big and hard to subset. Who asked for a subset? > Amongst the Emacs Lisp Coding Conventions it is suggested: > > * Please don't require the `cl' package of Common Lisp extensions at > run time. Use of this package is optional, and it is not part of > the standard Emacs namespace. If your package loads `cl' at run > time, that could cause name clashes for users who don't use that > package. > > However, there is no problem with using the `cl' package at compile > time, for the sake of macros. You do that like this: > > (eval-when-compile (require 'cl)) > > Hm. I think name clashes are largely a non-problem; a package author > would be insane to define cl functions/macros incompatibly, wouldn't > they? > > Ways to ameliorate this situation include splitting cl into several > separate independent libraries, moving ultra-nifty bits into subr.el, > or defining compiler macros for the more popular functions. > > If you just don't want to see the warnings then try frobbing > `byte-compile-warnings' (untested). This is entirely negating the point of Common-Lisp and the `cl' package. I don't use Microsoft-Word because I don't want to be locked into their proprietary file format. By the same token, as much as possible, I don't want to be locked into emacs lisp specificisms. Everytime there is an emacs function that have an equivalent in Common-Lisp, I'll use the Common-Lisp version. This gives me the big bonus to be able to use most of my lisp code programmed on emacs also on any other lisp environment. But I guess that this gives the same cold sweat to Stallman than to Gates, to see that some users of his programs may want to use concurent programs! What if suddently GNUS or VM or Kiwi could be compiled and used with cmucl or clisp? Horror! I don't mind if features specific to the emacs editor are hard linked to it (instead of, for example, being programmed as a nice portable Common-Lisp package). There may have valid technical reasons for it, or I could even agree with their moral reasons for it. But if I use emacs for prototyping lisp code, for scripting, or even to program some personal interactive tools, why should they and all the lisp libraries I write be locked to emacs lisp? If emacs developers are worried by name clashes, what are they waiting for implementing Common-Lisp packages? -- __Pascal_Bourguignon__ http://www.informatimago.com/ ---------------------------------------------------------------------- Do not adjust your mind, there is a fault in reality. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Some racism in emacs! 2003-06-02 6:42 ` Pascal Bourguignon @ 2003-06-02 9:46 ` John Paul Wallington 2003-06-02 13:08 ` Kai Großjohann 0 siblings, 1 reply; 6+ messages in thread From: John Paul Wallington @ 2003-06-02 9:46 UTC (permalink / raw) Pascal Bourguignon <spam@thalassa.informatimago.com> wrote: > John Paul Wallington <jpw@gnu.org> writes: >> The cl library, like Common Lisp, is big and hard to subset. > > Who asked for a subset? The coding conventions say not to make runtime use of cl. IMHO, the most likely to succeed way to nullify this convention is to split cl into independent parts and for libraries to require what they need at runtime. But subsetting cl is almost as hard as subsetting Common Lisp. >> Amongst the Emacs Lisp Coding Conventions it is suggested: >> >> * Please don't require the `cl' package of Common Lisp extensions at >> run time. Use of this package is optional, and it is not part of >> the standard Emacs namespace. If your package loads `cl' at run >> time, that could cause name clashes for users who don't use that >> package. >> >> However, there is no problem with using the `cl' package at compile >> time, for the sake of macros. You do that like this: >> >> (eval-when-compile (require 'cl)) >> >> Hm. I think name clashes are largely a non-problem; a package author >> would be insane to define cl functions/macros incompatibly, wouldn't >> they? >> >> Ways to ameliorate this situation include splitting cl into several >> separate independent libraries, moving ultra-nifty bits into subr.el, >> or defining compiler macros for the more popular functions. >> >> If you just don't want to see the warnings then try frobbing >> `byte-compile-warnings' (untested). > > This is entirely negating the point of Common-Lisp and the `cl' package. > > I don't use Microsoft-Word because I don't want to be locked into > their proprietary file format. > > By the same token, as much as possible, I don't want to be locked into > emacs lisp specificisms. > > Everytime there is an emacs function that have an equivalent in > Common-Lisp, I'll use the Common-Lisp version. This gives me the big > bonus to be able to use most of my lisp code programmed on emacs also > on any other lisp environment. I see. But cl doesn't magically make Emacs Lisp into Common Lisp. I guess you could write sizable code that does the same thing under both, but would it particularly suit either? > But I guess that this gives the same cold sweat to Stallman than to > Gates, to see that some users of his programs may want to use > concurent programs! What if suddently GNUS or VM or Kiwi could be > compiled and used with cmucl or clisp? Horror! > > > I don't mind if features specific to the emacs editor are hard linked > to it (instead of, for example, being programmed as a nice portable > Common-Lisp package). There may have valid technical reasons for it, > or I could even agree with their moral reasons for it. But if I use > emacs for prototyping lisp code, for scripting, or even to program > some personal interactive tools, why should they and all the lisp > libraries I write be locked to emacs lisp? Because that's the way it is. Emacs implements its own dialect. I imagine an Emacs written in Common Lisp would probably be better off using Common Lisp as its extension language. > If emacs developers are worried by name clashes, what are they waiting > for implementing Common-Lisp packages? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Some racism in emacs! 2003-06-02 9:46 ` John Paul Wallington @ 2003-06-02 13:08 ` Kai Großjohann 2003-06-02 16:00 ` David Kastrup 0 siblings, 1 reply; 6+ messages in thread From: Kai Großjohann @ 2003-06-02 13:08 UTC (permalink / raw) John Paul Wallington <jpw@gnu.org> writes: > Because that's the way it is. Emacs implements its own dialect. I wish Emacs Lisp was based on CL. *dream* -- This line is not blank. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Some racism in emacs! 2003-06-02 13:08 ` Kai Großjohann @ 2003-06-02 16:00 ` David Kastrup 0 siblings, 0 replies; 6+ messages in thread From: David Kastrup @ 2003-06-02 16:00 UTC (permalink / raw) kai.grossjohann@gmx.net (Kai Großjohann) writes: > John Paul Wallington <jpw@gnu.org> writes: > > > Because that's the way it is. Emacs implements its own dialect. > > I wish Emacs Lisp was based on CL. > > *dream* <URL:http://www.cliki.net/CL-Emacs> -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-06-02 16:00 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2003-06-01 6:05 Some racism in emacs! Pascal Bourguignon 2003-06-01 7:41 ` John Paul Wallington 2003-06-02 6:42 ` Pascal Bourguignon 2003-06-02 9:46 ` John Paul Wallington 2003-06-02 13:08 ` Kai Großjohann 2003-06-02 16:00 ` 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.