emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs Lisp's future


From: Helmut Eller
Subject: Re: Emacs Lisp's future
Date: Tue, 11 Oct 2016 09:47:54 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

On Mon, Oct 10 2016, Richard Stallman wrote:

> The reason namespaces systems do not fit well into Lisp
> is that they have to operate in 'read', in the choice of which
> symbol object you get.

I would say that namespaces manage symbols.  In contrast, modules manage
bindings.

The annoyance in Common Lisp is mostly that packages have to exist
before READ can intern symbols in a particular package.  That would be
problematic for autoload cookies or customizations in .emacs which are
commonly executed before loading the code that actually defines the
package.

The other annoyance in Common Lisp is that occasionally one gets name
conflict errors when importing a package because a symbol was
accidentally interned in the current package with READ.  People then
often get confused by the error message and quickly jump to the
conclusion that the package system must suck.  It's in fact a pilot
error and the package system just does its job of keeping the namespace
clean.

> I looked very briefly at the Clojure namespace spec and saw that it
> operates as part of evaluation, not as part of reading.  Perhaps that
> explains why it is usable.  Namespaces can work reasonably well as
> part of evaluation.  However, that doesn't fit Lisp.
>
> Clojure is not Lisp.

I guess then Scheme isn't Lisp either.

BTW, Rep, the Lisp dialect used by the Sawfish window manager which
initially looked very similar to Emacs Lisp, also eventually added a
module system.  Apparently without too much trouble.

Helmut




reply via email to

[Prev in Thread] Current Thread [Next in Thread]