emacs-devel
[Top][All Lists]
Advanced

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

Re: Emacs Lisp's future


From: Elias Mårtenson
Subject: Re: Emacs Lisp's future
Date: Tue, 11 Oct 2016 22:44:01 +0800

On 11 October 2016 at 15:47, Helmut Eller <address@hidden> wrote:
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.

That's an interesting way of putting it.
 
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.

That can be dealt with by transparently creating a package during READ. Common Lisp doesn't do this, but it can be argued that it should.
 
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.

What I do is simply never importing symbols from other packages. If I need to refer to a symbol in a different package, I always fully qualify it.

If a package system was implemented in Emacs Lisp, it would make sense to enforce this.

Elias

reply via email to

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