* is requiring cl bad? @ 2012-12-16 9:29 Ivan Kanis 2012-12-16 10:14 ` Xue Fuqiao 2012-12-16 17:06 ` Stefan Monnier 0 siblings, 2 replies; 15+ messages in thread From: Ivan Kanis @ 2012-12-16 9:29 UTC (permalink / raw) To: emacs devel Hello, I was under the impression that requiring cl was bad (TM). I can't remember why. Is it still so? -- Ivan Kanis http://ivan.kanis.fr Friendship is like a sheltering tree. -- Samuel Taylor Coleridge ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: is requiring cl bad? 2012-12-16 9:29 is requiring cl bad? Ivan Kanis @ 2012-12-16 10:14 ` Xue Fuqiao 2012-12-16 10:26 ` Pascal J. Bourguignon 2012-12-16 11:00 ` Ivan Kanis 2012-12-16 17:06 ` Stefan Monnier 1 sibling, 2 replies; 15+ messages in thread From: Xue Fuqiao @ 2012-12-16 10:14 UTC (permalink / raw) To: Ivan Kanis; +Cc: emacs devel On Sun, 16 Dec 2012 10:29:30 +0100 Ivan Kanis <ivan.kanis@googlemail.com> wrote: > I was under the impression that requiring cl was bad (TM). I can't > remember why. Is it still so? You can see these pages: http://lists.gnu.org/archive/html/emacs-devel/2003-08/msg00436.html http://www.gnu.org/gnu/rms-lisp.html http://lists.gnu.org/archive/html/emacs-devel/2007-09/msg01472.html BTW, what does "TM" mean(English is not my native language)? -- Best regards, Xue Fuqiao. http://www.emacswiki.org/emacs/XueFuqiao ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: is requiring cl bad? 2012-12-16 10:14 ` Xue Fuqiao @ 2012-12-16 10:26 ` Pascal J. Bourguignon 2012-12-16 10:36 ` Xue Fuqiao 2012-12-16 11:00 ` Ivan Kanis 1 sibling, 1 reply; 15+ messages in thread From: Pascal J. Bourguignon @ 2012-12-16 10:26 UTC (permalink / raw) To: emacs-devel Xue Fuqiao <xfq.free@gmail.com> writes: > On Sun, 16 Dec 2012 10:29:30 +0100 > Ivan Kanis <ivan.kanis@googlemail.com> wrote: > >> I was under the impression that requiring cl was bad (TM). I can't >> remember why. Is it still so? > > You can see these pages: > http://lists.gnu.org/archive/html/emacs-devel/2003-08/msg00436.html > http://www.gnu.org/gnu/rms-lisp.html > http://lists.gnu.org/archive/html/emacs-devel/2007-09/msg01472.html > > BTW, what does "TM" mean(English is not my native language)? It should be written as: ™ meaning Trade Mark, meaning "cl is bad" is a registered trade mark. No it's not, but it's as famous as if it was. -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: is requiring cl bad? 2012-12-16 10:26 ` Pascal J. Bourguignon @ 2012-12-16 10:36 ` Xue Fuqiao 0 siblings, 0 replies; 15+ messages in thread From: Xue Fuqiao @ 2012-12-16 10:36 UTC (permalink / raw) To: Pascal J. Bourguignon; +Cc: emacs-devel On Sun, 16 Dec 2012 11:26:10 +0100 "Pascal J. Bourguignon" <pjb@informatimago.com> wrote: > It should be written as: ™ meaning Trade Mark, meaning "cl is bad" is a > registered trade mark. No it's not, but it's as famous as if it was. Thanks for your explanation. -- Best regards, Xue Fuqiao. http://www.emacswiki.org/emacs/XueFuqiao ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: is requiring cl bad? 2012-12-16 10:14 ` Xue Fuqiao 2012-12-16 10:26 ` Pascal J. Bourguignon @ 2012-12-16 11:00 ` Ivan Kanis 1 sibling, 0 replies; 15+ messages in thread From: Ivan Kanis @ 2012-12-16 11:00 UTC (permalink / raw) To: Xue Fuqiao; +Cc: emacs devel Hi Xue, I guess my point is if I decide to use CL functions I should not be polluted with warnings when I compile. To get rid of all warnings I had to put this on top: (require 'cl) and tack at the end: ;; Local Variables: ;; byte-compile-warnings: (not cl-functions) ;; End: It shouldn't be so obscure. At least it ought to be documented somewhere... Xue Fuqiao <xfq.free@gmail.com> wrote: > On Sun, 16 Dec 2012 10:29:30 +0100 > Ivan Kanis <ivan.kanis@googlemail.com> wrote: > >> I was under the impression that requiring cl was bad (TM). I can't >> remember why. Is it still so? > > You can see these pages: > http://lists.gnu.org/archive/html/emacs-devel/2003-08/msg00436.html > http://www.gnu.org/gnu/rms-lisp.html > http://lists.gnu.org/archive/html/emacs-devel/2007-09/msg01472.html Thanks for the links it made interesting reading. I understand RMS doesn't like Common Lisp because it uses weird keywords. That is fine by me. > BTW, what does "TM" mean(English is not my native language)? Trade Mark, it's just a joke. -- Ivan Kanis http://ivan.kanis.fr A cruel crafty crocodile, Which in false grief hiding his harmful guile, Doth weep full sore, and sheddeth tender tears. -- Edmund Spenser ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: is requiring cl bad? 2012-12-16 9:29 is requiring cl bad? Ivan Kanis 2012-12-16 10:14 ` Xue Fuqiao @ 2012-12-16 17:06 ` Stefan Monnier 2012-12-17 19:09 ` Pascal J. Bourguignon 2012-12-17 20:58 ` Ivan Kanis 1 sibling, 2 replies; 15+ messages in thread From: Stefan Monnier @ 2012-12-16 17:06 UTC (permalink / raw) To: Ivan Kanis; +Cc: emacs devel > I was under the impression that requiring cl was bad (TM). I can't > remember why. Is it still so? The CL package is unclean w.r.t to its use of the namespace. Using its macros is tolerated because it only imposes this namespace mess during byte-compilation of your package, but using its functions imposes the mess during actual use of your package. 24.3 finally provides an alternative: `cl-lib' which offers the same functionality but in a namespace-clean way (i.e. using a "cl-" prefix everywhere). Stefan ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: is requiring cl bad? 2012-12-16 17:06 ` Stefan Monnier @ 2012-12-17 19:09 ` Pascal J. Bourguignon 2012-12-18 1:58 ` Tony Day 2012-12-20 4:46 ` David De La Harpe Golden 2012-12-17 20:58 ` Ivan Kanis 1 sibling, 2 replies; 15+ messages in thread From: Pascal J. Bourguignon @ 2012-12-17 19:09 UTC (permalink / raw) To: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> I was under the impression that requiring cl was bad (TM). I can't >> remember why. Is it still so? > > The CL package is unclean w.r.t to its use of the namespace. Using its > macros is tolerated because it only imposes this namespace mess during > byte-compilation of your package, but using its functions imposes the > mess during actual use of your package. > > 24.3 finally provides an alternative: `cl-lib' which offers the > same functionality but in a namespace-clean way (i.e. using a "cl-" > prefix everywhere). This is a silly solution. The right solution is to implement a package system. -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: is requiring cl bad? 2012-12-17 19:09 ` Pascal J. Bourguignon @ 2012-12-18 1:58 ` Tony Day 2012-12-20 4:46 ` David De La Harpe Golden 1 sibling, 0 replies; 15+ messages in thread From: Tony Day @ 2012-12-18 1:58 UTC (permalink / raw) To: Pascal J. Bourguignon; +Cc: emacs-devel On 18 Dec 2012, at 06:09, Pascal J. Bourguignon <pjb@informatimago.com> wrote: >> >> 24.3 finally provides an alternative: `cl-lib' which offers the >> same functionality but in a namespace-clean way (i.e. using a "cl-" >> prefix everywhere). > > This is a silly solution. > The right solution is to implement a package system. FWIW, I had a lot of trouble with cl when I started learning elisp. Did I have to learn the entire cl way of doing things to be proficient in emacs coding? Why was it 'special' in comparison to any other library/package but not so special as to be fully part of elisp? In retrospect, treating cl functionality as non-core helped accelerate my learning phase and better understand how to write useful emacs code. cl-lib is an awesome library that I hope to understand and use properly (one day). That it was partially tolerated in the past is one of those difficult to reverse mistakes and I think the solution is quite respectful and graceful considering. Tony ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: is requiring cl bad? 2012-12-17 19:09 ` Pascal J. Bourguignon 2012-12-18 1:58 ` Tony Day @ 2012-12-20 4:46 ` David De La Harpe Golden 2012-12-20 5:20 ` Ivan Kanis 2012-12-20 9:16 ` Helmut Eller 1 sibling, 2 replies; 15+ messages in thread From: David De La Harpe Golden @ 2012-12-20 4:46 UTC (permalink / raw) To: Emacs-devel On 17/12/12 19:09, Pascal J. Bourguignon wrote: >> 24.3 finally provides an alternative: `cl-lib' which offers the >> same functionality but in a namespace-clean way (i.e. using a "cl-" >> prefix everywhere). > > This is a silly solution. > The right solution is to implement a package system. > The consistent-prefix approach may be a C-like solution, but is still noticeably better than the previous conflicty mess, and widely used for other emacs lisp libs. But regarding the idea of "a package system" in particular, as you may mean a system similar to common lisp "packages": If emacs ever did go toward adding new facilities in the general area of modularity (however unlikely it is in reality in the near future), I reckon Ron Garret's common lisp land "lexicons" work [1] might be a better "lispy modularity thingy" for emacs lisp to be inspired by than common lisp packages in particular. At least, I'd take a hard look at lexicons (and at least glance at what some other languages do), before just blindly adding common lisp style packages. Emacs lisp is lexically scoped now after all. To people coming from quite a few other languages with more [nowadays-]conventional module systems, lexicons might well seem less weird than packages. In emacs lisp land there is obviously no prior usage of common lisp style packages in the first place (yes I am vaguely aware you can feck about with non-default obarrays in emacs lisp for some purposes, but meh), unlike the situation in common lisp land where inertia and compat concerns will probably keep most people on packages anyway despite the existence of lexicons there now. [1] http://www.flownet.com/ron/lisp/lexicons.pdf """ Lexicons are first-class global lexical environments, what are sometimes called "modules" or "namespaces" in other languages. [...] instead of mapping strings to symbols, lexicons map symbols to (global) bindings. """ ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: is requiring cl bad? 2012-12-20 4:46 ` David De La Harpe Golden @ 2012-12-20 5:20 ` Ivan Kanis 2012-12-20 9:16 ` Helmut Eller 1 sibling, 0 replies; 15+ messages in thread From: Ivan Kanis @ 2012-12-20 5:20 UTC (permalink / raw) To: David De La Harpe Golden; +Cc: Emacs-devel David De La Harpe Golden <david@harpegolden.net> wrote: > On 17/12/12 19:09, Pascal J. Bourguignon wrote: >>> 24.3 finally provides an alternative: `cl-lib' which offers the >>> same functionality but in a namespace-clean way (i.e. using a "cl-" >>> prefix everywhere). >> >> This is a silly solution. >> The right solution is to implement a package system. >> > If emacs ever did go toward adding new facilities in the general area > of modularity (however unlikely it is in reality in the near future), Sounds like a good candidate for emacs 25. Someone complained we didn't have a roadmap... ;) > I reckon Ron Garret's common lisp land "lexicons" work [1] Thanks for the link, I will read it later. -- Ivan Kanis http://ivan.kanis.fr Temporary routing anomaly. -- BOFH excuse number 35 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: is requiring cl bad? 2012-12-20 4:46 ` David De La Harpe Golden 2012-12-20 5:20 ` Ivan Kanis @ 2012-12-20 9:16 ` Helmut Eller 2012-12-21 7:05 ` David De La Harpe Golden 1 sibling, 1 reply; 15+ messages in thread From: Helmut Eller @ 2012-12-20 9:16 UTC (permalink / raw) To: emacs-devel On Thu, Dec 20 2012, David De La Harpe Golden wrote: > If emacs ever did go toward adding new facilities in the general area > of modularity (however unlikely it is in reality in the near future), > I reckon Ron Garret's common lisp land "lexicons" work [1] might be a > better "lispy modularity thingy" for emacs lisp to be inspired by than > common lisp packages in particular. At least, I'd take a hard look at > lexicons (and at least glance at what some other languages do), before > just blindly adding common lisp style packages. Have you actually taken a "hard look" at Ron Garret's lexicons? What was your experience? I played with them a few years back, but I quickly concluded that lexicons are only a crude prototype and that it was never used in the "field"; not something I would use. Ron Garret's code only worked with Clozure CL and since then CCL's internals have changed a bit so that lexicons no longer work. Common Lisp's packages are not prefect, but they get the job done. The problems (and workarounds) are by now well known. > Emacs lisp is lexically scoped now after all. If you want Scheme-like modules based on lexical scoping you will also need hygienic macros. (Something that Common Lisp nicely avoids.) Helmut ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: is requiring cl bad? 2012-12-20 9:16 ` Helmut Eller @ 2012-12-21 7:05 ` David De La Harpe Golden 2012-12-21 9:24 ` Helmut Eller 0 siblings, 1 reply; 15+ messages in thread From: David De La Harpe Golden @ 2012-12-21 7:05 UTC (permalink / raw) To: Helmut Eller; +Cc: emacs-devel On 20/12/12 09:16, Helmut Eller wrote: > Have you actually taken a "hard look" at Ron Garret's lexicons? > What was your experience? I played with them a few years back, but I quickly > concluded that lexicons are only a crude prototype Well, the last version I looked much at was ~2.0 when he started to reuse packages extensively as part of the underlying implementation (something I disliked actually [1], but he saw lexicons as a complete replacement for packages, I remember in the CL case I would have preferred if they had been independent facilities (but my concerns about packages vs. lexicons in the CL cases /would not apply/ here in emacs land, because there are no packages)) > and that it was never used in the "field"; not something I > would use. Not exactly mature, no - but hey, was new, shrug. Anyway, there's presumably no way at his /implementation/ could be reused for emacs unless emacs was first made into a common lisp. However, I mentioned lexicons as something to look at for inspiration for a hypothetical emacs system: the quality of Ron's actual implementation for [C]CL is not of particular concern for that purpose, in fact you could avoid looking at it completely (though it appears to be liberally licensed) and just read the paper for that purpose. >> Emacs lisp is lexically scoped now after all. > > If you want Scheme-like modules based on lexical scoping you will also > need hygienic macros. (Something that Common Lisp nicely avoids.) > Ron actually presented lexicons plus an escaping hack as an /alternative/ to scheme-style hygienic macros in his paper, mind, you may or may not be convinced that's better than a hygienic macro DSL, not sure I was. I figure implementation innards would need amendment regardless in the emacs case, practically if not in theory (I didn't mean to suggest lexicons be built on top of existing facilities at a purely lisp level or something in the emacs case, whereas despite CCL-isms, Ron used mostly portable CL) [1] http://coding.derkeiler.com/Archive/Lisp/comp.lang.lisp/2008-12/msg00359.html ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: is requiring cl bad? 2012-12-21 7:05 ` David De La Harpe Golden @ 2012-12-21 9:24 ` Helmut Eller 0 siblings, 0 replies; 15+ messages in thread From: Helmut Eller @ 2012-12-21 9:24 UTC (permalink / raw) To: emacs-devel On Fri, Dec 21 2012, David De La Harpe Golden wrote: > On 20/12/12 09:16, Helmut Eller wrote: > >> Have you actually taken a "hard look" at Ron Garret's lexicons? >> What was your experience? I played with them a few years back, but I quickly >> concluded that lexicons are only a crude prototype > > Well, the last version I looked much at was ~2.0 when he started to > reuse packages extensively as part of the underlying implementation > (something I disliked actually [1], but he saw lexicons as a complete > replacement for packages, I remember in the CL case I would have > preferred if they had been independent facilities (but my concerns > about packages vs. lexicons in the CL cases /would not apply/ here in > emacs land, because there are no packages)) Emacs symbols may not have packages but (funcall '<some-symbol>) is used a lot in Emacs Lisp. AFAICS, modules based on lexical scoping don't handle this case, because funcall doesn't resolve the symbol to a module binding. Which module should be used at runtime? >> and that it was never used in the "field"; not something I >> would use. > > Not exactly mature, no - but hey, was new, shrug. Anyway, there's > presumably no way at his /implementation/ could be reused for emacs > unless emacs was first made into a common lisp. > > However, I mentioned lexicons as something to look at for inspiration > for a hypothetical emacs system: the quality of Ron's actual > implementation for [C]CL is not of particular concern for that > purpose, in fact you could avoid looking at it completely (though it > appears to be liberally licensed) and just read the paper for that > purpose. Some ideas look nice on paper but when used in practice all sorts of problems appear that aren't covered in the paper. IMO lexicons fall into that category. >>> Emacs lisp is lexically scoped now after all. >> >> If you want Scheme-like modules based on lexical scoping you will also >> need hygienic macros. (Something that Common Lisp nicely avoids.) >> > > Ron actually presented lexicons plus an escaping hack as an > /alternative/ to scheme-style hygienic macros in his paper, mind, you > may or may not be convinced that's better than a hygienic macro DSL, > not sure I was. Either way you need to resolve a symbol to the module binding. So the result of a macro must either contain the resolved binding (if you do the resolution early) or the symbol plus the module (in some way) to that the compiler can do the resolution. > I figure implementation innards would need amendment regardless in the > emacs case, practically if not in theory (I didn't mean to suggest > lexicons be built on top of existing facilities at a purely lisp level > or something in the emacs case, whereas despite CCL-isms, Ron used > mostly portable CL) I would not call this "mostly portable" because the compiler patch is crucial and it was not even portable to the next version of the compiler. Helmut ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: is requiring cl bad? 2012-12-16 17:06 ` Stefan Monnier 2012-12-17 19:09 ` Pascal J. Bourguignon @ 2012-12-17 20:58 ` Ivan Kanis 2012-12-18 4:04 ` Stefan Monnier 1 sibling, 1 reply; 15+ messages in thread From: Ivan Kanis @ 2012-12-17 20:58 UTC (permalink / raw) To: emacs devel Stefan Monnier <monnier@iro.umontreal.ca> wrote: >> I was under the impression that requiring cl was bad (TM). I can't >> remember why. Is it still so? > > The CL package is unclean w.r.t to its use of the namespace. Using its > macros is tolerated because it only imposes this namespace mess during > byte-compilation of your package, but using its functions imposes the > mess during actual use of your package. > > 24.3 finally provides an alternative: `cl-lib' which offers the > same functionality but in a namespace-clean way (i.e. using a "cl-" > prefix everywhere). In case someone is reading this thread, here's what I did in the end: (require 'cl-lib) (eval-when-compile (require 'cl)) Rename all common lisp functions, for example coerce -> cl-coerce. I had to keep 'cl for macro expansion such as incf. I removed the following at the end of the file : ;; Local Variables: ;; byte-compile-warnings: (not cl-functions) ;; End: Now it compiles without warning. -- Ivan Kanis http://ivan.kanis.fr The essence of science: ask an impertinent question, and you are on the way to a pertinent answer. -- Jacob Bronowski I am listening to "Coldplay - In My Place". ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: is requiring cl bad? 2012-12-17 20:58 ` Ivan Kanis @ 2012-12-18 4:04 ` Stefan Monnier 0 siblings, 0 replies; 15+ messages in thread From: Stefan Monnier @ 2012-12-18 4:04 UTC (permalink / raw) To: Ivan Kanis; +Cc: emacs devel > Rename all common lisp functions, for example coerce -> cl-coerce. I had > to keep 'cl for macro expansion such as incf. If you're requiring cl-lib for cl-coerce, then you may as well use cl-incf and drop `cl' altogether. Stefan ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2012-12-21 9:24 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-12-16 9:29 is requiring cl bad? Ivan Kanis 2012-12-16 10:14 ` Xue Fuqiao 2012-12-16 10:26 ` Pascal J. Bourguignon 2012-12-16 10:36 ` Xue Fuqiao 2012-12-16 11:00 ` Ivan Kanis 2012-12-16 17:06 ` Stefan Monnier 2012-12-17 19:09 ` Pascal J. Bourguignon 2012-12-18 1:58 ` Tony Day 2012-12-20 4:46 ` David De La Harpe Golden 2012-12-20 5:20 ` Ivan Kanis 2012-12-20 9:16 ` Helmut Eller 2012-12-21 7:05 ` David De La Harpe Golden 2012-12-21 9:24 ` Helmut Eller 2012-12-17 20:58 ` Ivan Kanis 2012-12-18 4:04 ` Stefan Monnier
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.