How close is elisp to CL now?

[juliewith]

Not being proficient in Lisp but wanting to be, I was wondering if the
lexical scoping in 24.x has now pushed elisp closer to Common Lisp in
capabilities. If so how close? Could elisp now (potentially) do all the
"higher level" sorts of things CL does?



--
View this message in context: http://emacs.1067599.n5.nabble.com/How-close-is-elisp-to-CL-now-tp272247.html
Sent from the Emacs - Help mailing list archive at Nabble.com.

[Burton Samograd]

juliewith <galaxybe...@gmail.com> writes:

> Not being proficient in Lisp but wanting to be, I was wondering if the
> lexical scoping in 24.x has now pushed elisp closer to Common Lisp in
> capabilities. If so how close? Could elisp now (potentially) do all the
> "higher level" sorts of things CL does?

Yes. Using the current cl-lib I have taken CL code with some minor name
changs and run it directly in emacs without problems.

--
Burton Samograd

[Didier Verna]

juliewith <galaxybe...@gmail.com> wrote:

> Not being proficient in Lisp but wanting to be, I was wondering if the
> lexical scoping in 24.x has now pushed elisp closer to Common Lisp in
> capabilities. If so how close? Could elisp now (potentially) do all
> the "higher level" sorts of things CL does?

Lexical scope brings Emacs Lisp closer to *any* sane Lisp (which
should be lexically scoped by default[1]). This, in fact, has little
to do with Common Lisp. One could even argue that it is the opposite,
since one disctinctive feature of Common Lisp is precisely to offer
dynamic scoping, provided that you ask for it explicitely.

You may be interested in reading
http://random-state.net/features-of-common-lisp.html for a nice list
of Common Lisp features (some of them are arguably "general Lisp
features" rather than Common Lisp ones).


Footnotes:
[1] Although honestly, in more than 15 years of elisp hacking, dynamic
scope screwed me up less than a dozen times...

--
ELS 2013, June 3/4, Madrid, Spain: http://els2013.european-lisp-symposium.org

Scientific site: http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com

[Matt Price]

how much closer does this get us to something like a 'concurrent
emacs', in which (e.g.) my emacs mailer can do background checks for
incoming mail while I am editing? For the moment I've abandoned emacs
as a mail environment precisely because the lack of that feature so
often made my work grind to a halt.

[Burton Samograd]

Matt Price <mopt...@gmail.com> writes:

> how much closer does this get us to something like a 'concurrent
> emacs', in which (e.g.) my emacs mailer can do background checks for
> incoming mail while I am editing? For the moment I've abandoned emacs
> as a mail environment precisely because the lack of that feature so
> often made my work grind to a halt.

There is work being done on a threaded emacs, but there is still much
work to be done. A suggested fix for the mail problem you state is to
start another instance of emacs and run your mail client there.

One thing I've noticed is that network communication in emacs is
normally handled with a libevent system (or something similar) so
network communication acts like it's in a separate process. I'm not
sure if clients like gnus take advantage of this type of network
communication yet though, but I think a blockless email client is
possible with current emacs technology.

--
Burton Samograd

[William Gardella]

Medium/long-term, yes, one goal of introducing lexical scoping is to
make concurrency possible. In the meantime, one possibility short of
concurrency--being pursued by org-mode for its new exporter library now
in tests for the 8.0 release, and also by Nic Ferrier's Elnode (
https://github.com/nicferrier/elnode ), and by John Wiegley's async.el--
is to use asynchronous Emacsen for big jobs and communications jobs.

Also, for Gnus specifically, emacs --batch jobs combined with using Gnus
in "Unplugged" mode is a good setup for background mail checking and
fast, non-blocking reading. See (info "(gnus) Batching Agents"); I run
a script similar to the one there as an hourly cron job, then read
offline.

--
Regards,
WGG
I use grml (http://grml.org/)

[Pascal J. Bourguignon]

juliewith <galaxybe...@gmail.com> writes:

> Not being proficient in Lisp but wanting to be, I was wondering if the
> lexical scoping in 24.x has now pushed elisp closer to Common Lisp in
> capabilities. If so how close? Could elisp now (potentially) do all the
> "higher level" sorts of things CL does?

Quite far, actually.

But with some work, you can get more closer to CL just writing elisp
code.

The main road block is the lack of reader macros, or otherwise lack of a
hook into the emacs lisp reader, to implement reading qualified symbols
(and other CL reader macros).

But apart from reading qualified symbols, CL packages could be
implemented now just with emacs lisp code (using obarrays).

However a lot is still missing:

True structures and CLOS objects. (They're simulated at the elisp level
with vectors).

Multidimensional arrays.

bignums, ratios, simple-floats, single-floats, double-floats,
long-floats, complexes.

Etc.


But IMO, it would be simplier and will give a better results (both
technically and politically) to reimplement the emacs VM (all the GNU
emacs C code) in Common Lisp, than to Common-lispify GNU emacs.

--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.

[Xavier Maillard]

That's awesome ! I did not see this change before I read the OP message.

Xavier
--
http://www.gnu.org
http://www.april.org
http://www.lolica.org

[juliewith]

Pascal J. Bourguignon wrote

> But IMO, it would be simplier and will give a better results (both
> technically and politically) to reimplement the emacs VM (all the GNU
> emacs C code) in Common Lisp, than to Common-lispify GNU emacs.
>

It does seem odd that emacs, being so powerful and such a world unto itself,
would have a junior version of Common Lisp. I can't help but believe elisp's
limitations are a huge drag on emacs overall. I vote for a CL makeover too.




--
View this message in context: http://emacs.1067599.n5.nabble.com/How-close-is-elisp-to-CL-now-tp272247p272278.html

[Joost Kremers]

Pascal J. Bourguignon wrote:
> But IMO, it would be simplier and will give a better results (both
> technically and politically) to reimplement the emacs VM (all the GNU
> emacs C code) in Common Lisp, than to Common-lispify GNU emacs.

you mean something like this:

http://tromey.com/blog/?p=709
http://tromey.com/blog/?p=751
http://tromey.com/blog/?p=778

?

not sure how much has happened with the project since january, but it
certainly sounds interesting.


--
Joost Kremers joostk...@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)

[Jambunathan K]

Joost Kremers <joostk...@yahoo.com> writes:

> Pascal J. Bourguignon wrote:
>> But IMO, it would be simplier and will give a better results (both
>> technically and politically) to reimplement the emacs VM (all the GNU
>> emacs C code) in Common Lisp, than to Common-lispify GNU emacs.
>
> you mean something like this:
>
> http://tromey.com/blog/?p=709
> http://tromey.com/blog/?p=751
> http://tromey.com/blog/?p=778
>
> ?
>
> not sure how much has happened with the project since january, but it
> certainly sounds interesting.

I see some activity some 3 months ago.

http://bzr.savannah.gnu.org/lh/emacs/concurrency/changes

I am not sure how experimental or current is that branch though.
--

[Julien Cubizolles]

William Gardella <garde...@gmail.com> writes:

> Burton Samograd <bur...@samograd.ca> writes:

> Also, for Gnus specifically, emacs --batch jobs combined with using Gnus
> in "Unplugged" mode is a good setup for background mail checking and
> fast, non-blocking reading. See (info "(gnus) Batching Agents"); I run
> a script similar to the one there as an hourly cron job, then read
> offline.

Let me get this straight : you have Gnus running unplugged and another
emacs instance is fetching messages with a cron job ? And the unplugged
Gnus refreshes its group with gnus-demon-add-handler ?

That could be the solution I've been looking for for a while. I guess
one could use this trick for any long process in Emacs (synchronization
through org-mobile-push comes to mind)

Julien.

[WJ]

Didier Verna wrote:

> Lexical scope brings Emacs Lisp closer to any sane Lisp (which

> should be lexically scoped by default[1]). This, in fact, has little
> to do with Common Lisp. One could even argue that it is the opposite,
> since one disctinctive feature of Common Lisp is precisely to offer
> dynamic scoping, provided that you ask for it explicitely.

The CL package adds some features that go beyond CL.

EMACS Lisp:

(require 'cl)
(defun* foo ((name (sex (age))))
(list age sex name))
(foo '(John (male (33))))

==> (33 male John)

Common Lisp:

(defun foo ((name (sex (age))))
(list age sex name))

; in: LAMBDA NIL
; (SB-INT:NAMED-LAMBDA FOO
; ((NAME (SEX (AGE))))
; (BLOCK FOO (LIST AGE SEX NAME)))
; ==>
; #'(SB-INT:NAMED-LAMBDA FOO
; ((NAME (SEX (AGE))))
; (BLOCK FOO (LIST AGE SEX NAME)))
;
; caught ERROR:
; Required argument is not a symbol: (NAME (SEX (AGE)))

[William Gardella]

That's the general idea, yes. And it works very smoothly. :)

--
-WGG

[Julien Cubizolles]

William Gardella <garde...@gmail.com> writes:

> Julien Cubizolles <j.cubi...@free.fr> writes:

>> Let me get this straight : you have Gnus running unplugged and another
>> emacs instance is fetching messages with a cron job ? And the unplugged
>> Gnus refreshes its group with gnus-demon-add-handler ?

> That's the general idea, yes. And it works very smoothly. :)

Do you use it with imap ? I'm running into a weird problem with this
setup : every time I run gnus-agent-batch, the gnus running unplugged
displays a new copy of each unread mail in the summary buffer for the
imap group.

Could you please send me the relevant parts of your .gnus.el so that I
can compare with mine ?

Julien.