I notice expressions like this used in comp.lang.lisp often;
" ... not only do I have (require 'cl) first thing in
my ~/.emacs, but I also have (load "load-cl") next... "
So I do wonder .. why ?
* Is it the 'good house-keeping' of requiring us to preface functions with
the exact package from which they originate ?
* Is 'cl (being a "subset") simply sufficient for most vanilla Lisp
programming ?
Where the Emacs manual says " ... Emacs provides a subset of Common Lisp in
the CL package."
* If I decide to include (require 'cl) and (load "load-cl") in my ~.emacs,
then I would need ALL its other packages ? Where the Emacs CL manual lists,
cl.el
cl-extra.el
cl-seq.el
cl-macs.el
where the Emacs CL manual section 2.2 says,
"The file cl.el includes all necessary autoload commands for the functions
and macros in the other three files. All you have to do is (require 'cl),
and cl.el will take care of pulling in the other files when they are
needed."
* So, you're still using a subset of Common Lisp. Why not use a complete
other implementation ? Is it for the 'good house-keeping' reason above ?
Or because simply a Listener/inferior-lisp subprocess etc is too much of a
hassle or overhead for simple or medium or coherent coding ? Similarly is
it that Slime is really too much or ultimately unnecessary for most Lisp
hacking ?
FWIW & FYI: I am working with one Lisp application, which sets up Slime and
an inferior-lisp in Emacs, uses CMUCL, and - although a bit fiddly - works
fine. I seem to have both CLISP and CMUCL on my machine. Lisps shown at
bottom.
Sorry for the naive question(s).
Ads.
[···@local ~]$ which lisp
/usr/bin/lisp
[···@local ~]$ which clisp
/usr/local/bin/clisp
[···@local ~]$ clisp
i i i i i i i ooooo o ooooooo ooooo ooooo
I I I I I I I 8 8 8 8 8 o 8 8
I \ `+' / I 8 8 8 8 8 8
\ `-+-' / 8 8 8 ooooo 8oooo
`-__|__-' 8 8 8 8 8
| 8 o 8 8 o 8 8
------+------ ooooo 8oooooo ooo8ooo ooooo 8
Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2006
[1]> (lisp-implementation-version)
"2.38 (2006-01-24) (built 3352213458) (memory 3352215255)"
[2]>
[···@local ~]$ lisp
CMU Common Lisp 19b (19B), running on xyz
With core: /usr/local/lib/cmucl/lib/lisp.core
Dumped on: Tue, 2005-06-28 12:09:58+12:00 on lorien
See <http://www.cons.org/cmucl/> for support information.
Loaded subsystems:
Python 1.1, target Intel x86
CLOS based on Gerd's PCL 2004/04/14 03:32:47
* (lisp-implementation-version)
;
"19b (19B)"
Adam <······@example.com> wrote:
> * So, you're still using a subset of Common Lisp. Why not use a complete
> other implementation ? Is it for the 'good house-keeping' reason above ?
> Or because simply a Listener/inferior-lisp subprocess etc is too much of a
> hassle or overhead for simple or medium or coherent coding ? Similarly is
> it that Slime is really too much or ultimately unnecessary for most Lisp
> hacking ?
It seems to me that you are mixing up two different things in your mind:
running a true Common Lisp session in you Emacs editor (just as you
would run a shell or compile session), and writing Common Lisp style
code in Emacs Lisp.
Emacs Lisp is used to program Emacs, but it is different from Common
Lisp. The cl *emacs* package provides Common Lisp idioms for Emacs Lisp.
--
MySpace: http://www.myspace.com/didierverna
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (1) 53 14 59 22 ······@xemacs.org
Didier Verna wrote:
> Emacs Lisp is used to program Emacs, but it is different from Common
> Lisp. The cl *emacs* package provides Common Lisp idioms for Emacs Lisp.
Errr, OK.
So, on the comp.lang.lisp group, many of the examples or discussions
showing Lisp code are in-effect examples in Emacs Lisp, (which, as luck
would have it, are transparent to Common Lisp and the other Lisps).
Maybe I understand that the *implementation-specific* examples, which may
depart sufficiently from Emacs Lisp, are rare enough to warrant a special
mention ?
So, is the function package prefix still 'good-house-keeping' ? Or just for
the exceptions ? Indeed I can't seem to find it in the Hyperspec - I'll
keep looking.
Adam <······@example.com> writes:
> Didier Verna wrote:
>
>> Emacs Lisp is used to program Emacs, but it is different from Common
>> Lisp. The cl *emacs* package provides Common Lisp idioms for Emacs Lisp.
>
> Errr, OK.
>
> So, on the comp.lang.lisp group, many of the examples or discussions
> showing Lisp code are in-effect examples in Emacs Lisp, (which, as luck
> would have it, are transparent to Common Lisp and the other Lisps).
Nope. Most of the examples in c.l.l are in Common Lisp, unless
otherwise indicated. There are many emacs newsgroups and mailing list
for discussing Emacs Lisp.
> Maybe I understand that the *implementation-specific* examples, which may
> depart sufficiently from Emacs Lisp, are rare enough to warrant a special
> mention ?
You are getting it wrong. Emacs Lisp is not the "standard" from which
other Lisps deviate, it is a special purpose Lisp for the Emacs
editor. For general programming, people use either Common Lisp or
Scheme.
HTH,
Tamas
Tamas Papp <······@gmail.com> wrote:
> You are getting it wrong. Emacs Lisp is not the "standard" from which
> other Lisps deviate, it is a special purpose Lisp for the Emacs
> editor. For general programming, people use either Common Lisp or
> Scheme.
As a matter of fact, Emacs Lisp is probably the worst Lisp
dialect ever :-) I, for one, would like to replace XEmacs's lisp engine
by a true Common Lisp one. But I know at least one other XEmacs
maintainer who would strongly disagree... his name is Mike Sperber.
See the problem ? :-)
--
MySpace: http://www.myspace.com/didierverna
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (1) 53 14 59 22 ······@xemacs.org
Didier Verna wrote:
> Tamas Papp <······@gmail.com> wrote:
>
>> You are getting it wrong. Emacs Lisp is not the "standard" from which
>> other Lisps deviate, it is a special purpose Lisp for the Emacs
>> editor. For general programming, people use either Common Lisp or
>> Scheme.
>
> As a matter of fact, Emacs Lisp is probably the worst Lisp
> dialect ever :-) I, for one, would like to replace XEmacs's lisp engine
> by a true Common Lisp one. But I know at least one other XEmacs
> maintainer who would strongly disagree... his name is Mike Sperber.
>
> See the problem ? :-)
You could try to agree on ISLISP, which should be easier to access from
both Common Lisp and Scheme.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Adam <······@example.com> wrote:
> Errr, OK.
>
> So, on the comp.lang.lisp group, many of the examples or discussions
> showing Lisp code are in-effect examples in Emacs Lisp,
No, Common Lisp. For Emacs Lisp, see comp.emacs and comp.emacs.xemacs.
> So, is the function package prefix still 'good-house-keeping' ? Or
> just for the exceptions ? Indeed I can't seem to find it in the
> Hyperspec - I'll keep looking.
Not sure what you're talking about, but Emacs Lisp doesn't have
Common Lisp packages[1], neither any kind of namespace support, so it's
a good idea to prefix your functions with the name of the library in
order to avoid name collision.
Footnotes:
[1] XEmacs has a notion of package, but this relates to packages as in
LaTeX or Debian packages for instance, that is, add-on libraries that can be
retreived, compiled, (un)installed automatically.
--
MySpace: http://www.myspace.com/didierverna
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (1) 53 14 59 22 ······@xemacs.org
Adam <······@example.com> writes:
> Didier Verna wrote:
>
>> Emacs Lisp is used to program Emacs, but it is different from Common
>> Lisp. The cl *emacs* package provides Common Lisp idioms for Emacs Lisp.
>
> Errr, OK.
>
> So, on the comp.lang.lisp group, many of the examples or discussions
> showing Lisp code are in-effect examples in Emacs Lisp, (which, as luck
> would have it, are transparent to Common Lisp and the other Lisps).
>
No. Very few of the code examples posted to c.l.l are for emacs lisp - most are
for common lisp. You do see some emacs related posts, but that is because many
people using common lisp use emacs as their development environment.
> Maybe I understand that the *implementation-specific* examples, which may
> depart sufficiently from Emacs Lisp, are rare enough to warrant a special
> mention ?
No, if anything, the other way around. Examples of emacs lisp should be
labelled that way. However, the proper place for emacs lisp is really in the
gnu.emacs.help group.
>
> So, is the function package prefix still 'good-house-keeping' ? Or just for
> the exceptions ? Indeed I can't seem to find it in the Hyperspec - I'll
> keep looking.
Not sure what your referring to here. However, if it is in reference to your
earlier post on (require 'cl) and (load "load-cl"), then you won't find much in
the hyperspec because thats emacs lisp and emacs lisp is NOT common lisp.
Tim
--
tcross (at) rapttech dot com dot au
Adam <······@example.com> writes:
> I notice expressions like this used in comp.lang.lisp often;
>
> " ... not only do I have (require 'cl) first thing in
> my ~/.emacs, but I also have (load "load-cl") next... "
>
> So I do wonder .. why ?
As explained in the other answers, (require 'cl) is emacs lisp to load
in emacs some Common Lisp features. If you're used to write Common
Lisp, it allows you to use a wider intersection of emacs lisp and
Common Lisp to program emacs. But it is still NOT Common Lisp, and
while some Common Lisp code could be run directly in emacs lisp, a lot
of Common Lisp code will break or behave very differently in emacs
lisp.
Now, for (load "load-cl"), this is the emacs lisp form used to load a
Common Lisp implemented in emacs lisp, emacs-cl.
http://www.lisp.se/emacs-cl/
Then you can launch a Common Lisp REPL in emacs with M-x emacs-cl RET
This is another Common Lisp just like CMUCL or clisp:
COMMON-LISP-USER> (list (lisp-implementation-type) (lisp-implementation-version))
("Emacs Common Lisp" "0.8")
The great thing about this implementation is that it's able to call
emacs lisp functions (remember, emacs symbols are in low-case, while
the Common Lisp reader by default convert to uppercase, so we have to
escape emacs-lisp symbols):
COMMON-LISP-USER> (progn (emacs-lisp:|switch-to-buffer|
(emacs-lisp:|set-buffer|
(emacs-lisp:|get-buffer-create| "Example")))
(emacs-lisp:|insert| "Hello!"))
NIL
COMMON-LISP-USER> (mapcar (function emacs-lisp:|buffer-name|)
(emacs-lisp:|buffer-list|))
("*Emacs Common Lisp*" "*followup to Adam on comp.lang.lisp*" "
*Minibuf-1*" "*Article*" "*Summary comp.lang.lisp*" "*Group*" "KILL"
"0shell" "0lisp-custom" "pa-loader.lisp" "pa-es.lisp"
"intergruas.lisp" "*scratch*" " *Minibuf-2*" "*Buffer List*"
".notes.utf-8" " *vm-nonexistent-summary*" "*Messages*" " *Minibuf-0*"
" *Echo Area 0*" " *Echo Area 1*" " *code-conversion-work*" " *table
cell cache*" "http-client.lisp" "regexp-ppcre.lisp" " *nntpd*" " *Gnus
agent overview*" " *gnus work*" " *Original Article*" " *Async
Prefetch Article*" " *Gnus Backlog*" " *canonical address*" " *extract
address components*" " *gnus article copy*" " *code-converting-work*"
"*sent followup to Thomas on fr.comp.os.unix*" " *server
news.individual.net nntp *nntpd**" " *server news.gmane.org nntp
*nntpd**" ".newsrc-dribble")
COMMON-LISP-USER>
So now, you can use Common Lisp to customize emacs, instead of emacs lisp.
The downside, is that not 100% of Common Lisp is implemented yet.
It is also possible to use most of Emacs Common Lisp directly from
emacs-lisp, the symbols from the COMMON-LISP package being in
uppercase, they are just directly interned in emacs-lisp. So you can
write in emacs-lisp:
(MAPCAR (function PACKAGE-NAME) (LIST-ALL-PACKAGES)) C-u C-x C-e
and get:
("COMMON-LISP-USER" "COMMON-LISP" "EMACS-COMMON-LISP-MOP"
"EMACS-COMMON-LISP" "EMACS-LISP" "KEYWORD")
Note that the Common Lisp special operators are not available in
emacs-lisp, obviously, since we're in emacs-lisp. So we have to use
the emacs-lisp operator function instead of the Common Lisp operator
FUNCTION, and they're very different: function is equivalent to quote.
Also, only the symbols from COMMON-LISP are available directly in
emacs-lisp, since emacs-lisp doesn't have packages, accessing symbols
from other CL packages is more complicated (better switch to the
Common Lisp REPL if you need that).
In any case, this allows you to use parts of emacs-cl in your emacs
functions and commands, which is the reason why I keep (load "load-cl")
in my "~/.emacs".
That said, using slime it is also possible to run Common Lisp code
from emacs-lisp (obviously) and to run emacs-lisp code from your
inferior Common Lisp (CMUCL, clisp, etc). So an alternative to
emacs-cl could be to launch an inferior lisp from slime and use these
"RPC":
;;;; emacs <-> common-lisp RPC with slime/swank
;;; In emacs, we can execute Common Lisp expressions:
(require 'slime)
(slime)
(setf slime-enable-evaluate-in-emacs t)
(defun eval-in-cl (cl-expression-string process-result-values)
(slime-eval-with-transcript
`(swank:eval-and-grab-output ,cl-expression-string)
(lexical-let ((here (current-buffer))
(process-result-values process-result-values))
(lambda (result-values)
(set-buffer here)
(funcall process-result-values result-values)))))
(eval-in-cl "(values 1 * (ext:! 20) (package-name *package*))"
(lambda (values)
(dolist (v values)
(insert (format "%s\n" v)))))
;; Returns:
;;
;; nil
;;
;; then later inserts:
;;
;; 1
;; (42 (EMACS-UNREADABLE |buffer| |*scratch*|))
;; 2432902008176640000
;; "COMMON-LISP-USER"
;;; In Common Lisp, we can execute emacs lisp expressions:
(defparameter *emacs-readtable* (copy-readtable))
(setf (readtable-case *emacs-readtable*) :preserve)
(set-syntax-from-char #\> #\) *emacs-readtable*)
(set-dispatch-macro-character
#\# #\<
(lambda (stream subchar dispchar)
`(emacs-unreadable ,@(read-delimited-list #\> stream t)))
*emacs-readtable*)
;; Probably more readtable patching would be in order.
;;
;; We could define CLOS proxies for emacs objects for a more seamless
;; integration. swank::eval-in-emacs process the CL form to make it
;; "emacs" (eg. downcase symbols, etc). It could convert CLOS proxies
;; to emacs lisp forms returning the corresponding emacs object.
(defun eval-in-emacs (form &optional nowait)
(let ((result (SWANK::EVAL-IN-EMACS `(format "%S" ,form) nowait))
(*readtable* *emacs-readtable*))
(with-input-from-string (in result)
(let ((result (read in nil in)))
result))))
(eval-in-emacs `(progn
(switch-to-buffer (buffer-named "*scratch*"))
(goto-char (point-max))
(insert ,(format nil "~%Hello~%"))
(list 42 (current-buffer))))
;; Switch to the *scratch* buffer,
;; goto the last position, and
;; inserts \nHello\n
;; then returns:
;; (42 (EMACS-UNREADABLE |buffer| |*scratch*|))
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
Adam <······@example.com> writes:
> I notice expressions like this used in comp.lang.lisp often;
>
> " ... not only do I have (require 'cl) first thing in
> my ~/.emacs, but I also have (load "load-cl") next... "
>
> So I do wonder .. why ?
>
> * Is it the 'good house-keeping' of requiring us to preface functions with
> the exact package from which they originate ?
>
> * Is 'cl (being a "subset") simply sufficient for most vanilla Lisp
> programming ?
> Where the Emacs manual says " ... Emacs provides a subset of Common Lisp in
> the CL package."
>
> * If I decide to include (require 'cl) and (load "load-cl") in my ~.emacs,
> then I would need ALL its other packages ? Where the Emacs CL manual lists,
> cl.el
> cl-extra.el
> cl-seq.el
> cl-macs.el
>
> where the Emacs CL manual section 2.2 says,
> "The file cl.el includes all necessary autoload commands for the functions
> and macros in the other three files. All you have to do is (require 'cl),
> and cl.el will take care of pulling in the other files when they are
> needed."
>
> * So, you're still using a subset of Common Lisp. Why not use a complete
> other implementation ? Is it for the 'good house-keeping' reason above ?
> Or because simply a Listener/inferior-lisp subprocess etc is too much of a
> hassle or overhead for simple or medium or coherent coding ? Similarly is
> it that Slime is really too much or ultimately unnecessary for most Lisp
> hacking ?
>
>
> FWIW & FYI: I am working with one Lisp application, which sets up Slime and
> an inferior-lisp in Emacs, uses CMUCL, and - although a bit fiddly - works
> fine. I seem to have both CLISP and CMUCL on my machine. Lisps shown at
> bottom.
>
>
> Sorry for the naive question(s).
>
> Ads.
I think you may have misunderstood things. The cl package is used to add common
lisp type functionality to emacs lisp. Many lispers find it easier to write
emacs extensions if the features they are accustomed to from CL are available.
There is no easy way to link emacs lisp functions with a full blown common lisp
implementation. The emacs cl package is not supposed to be for developing true
common lisp apps - for that use slime and your favorite cl implementation.
I'm not sure what the (load "load-cl") line is - thats not a standard emacs
function. It may be loading the OPs emacs-cl library or it could be setting up
his environment for working with common lisp or ......
Tim
--
tcross (at) rapttech dot com dot au