Matthieu Moy <[EMAIL PROTECTED]> writes: > Other back-ends are very carefull not to use it at runtime. > >> RMS is stepping down as Emacs maintainer (sometime; I'm not reading >> the emacs-devel list anymore, so I don't know if it has actually >> happened yet). > > That's not just RMS I think. > >> If the argument is "cl is slow" then the response is "it's fast enough >> for 90% of users" combined with "getting it right is more important >> than making it really fast". > > I believe the main argument is namespace pollution.
Hmm. If I'm writing "foo-mode", and I'm _not_ using cl, then I don't get the namespace polution. But if I depend on "bar-package", and it uses the cl runtime, then I those names do show up in my namespace. The real solution is to add namespaces to Emacs Lisp, but I suppose that's never going to happen. So then the solution is to switch to Eclipse (since Java has namespaces), or GPS (https://libre.adacore.com/gps/, an IDE written in Ada on top of Gtk - Ada has namespaces). Also Not Going to Happen :). > Last time I heard about it, the answer was roughly "everybody thinks > native common lisp rocks, but everybody agrees it sucks through an > emulation layer in Emacs". I personnally don't have a really strong > opinion on that, but we removed the runtime 'cl dependancy after > several user complaints. Ok, I guess that's a good enough reason. > ,----[ C-h f ecase RET ] > | ecase is a Lisp macro in ... > | ^^^^^^^^^^ > | [back] > `---- > > ,----[ C-h f defstruct RET ] > | defstruct is a Lisp macro in ... > | ^^^^^^^^^^ > | [back] > `---- > > Up to now, there's no _runtime_ dependancy. Good news ;-). Hmm. Those macros certainly generate a lot of code; I assumed that code was from the runtime part. So I'm no longer sure that xmtn is using cl runtime. Checking that via this mechanism will be tedious and error-prone; is there a better way? I guess the users who complained noticed that the cl runtime was being loaded. So we can just check for "loading cl" messages? -- -- Stephe _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
